search for: new_inod

new_inode() does not return ERR_PTR() but NULL in case of failure. Correct checking of the return value. Signed-off-by: Jan Kara <jack at suse.cz> --- fs/ocfs2/namei.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c index d5d808f..0372e...

...++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 2e3ea30..5b8d944 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -6499,6 +6499,16 @@ static int ocfs2_reflink_xattr_inline(struct ocfs2_xattr_reflink *args) } new_oi = OCFS2_I(args->new_inode); + /* + * Adjust extent record count to reserve space for extended attribute. + * Inline data count had been adjusted in ocfs2_duplicate_inline_data(). + */ + if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) && + !(ocfs2_inode_is_fast_symlink(args->new_inode))) { +...

...s gets to see > the inode, be it in ->read_inode() or after get_empty_inode(). > The rest is private business of that fs. That's what ->u is about, > after all... I did a quick check through the 2.4 tree looking for zero initializations on the ->u data in *_read_inode() and *_new_inode(). Some set individual fields to zero and others to non-zero values, some only set non-zero values, and some did memset(inode->u.*_i, 0, sizeof(inode->u.*_i)) before filling in their private data. Patch attached, and filesystem maintainers (as applicable) CC'd. UDF needs a bit of look...

Hi, I split the previous support security EA patch into four patches for review. Them besed on joel's xattr-28 branch and tao's patch "Merge xattr set transaction". 1: move new_inode out of the transaction. 2: add ocfs2_xattr_set_handle. 3: add security xattr APIs 4: add init_security in mknod. Best regards, tiger

Hi all, this series removes most users of the write_one_page API. These helpers internally call ->writepage which we are gradually removing from the kernel. Changes since v2: - more minix error handling fixes Changes since v1: - drop the btrfs changes (queue up in the btrfs tree) - drop the finaly move to jfs (can't be done without the btrfs patches) - fix the existing minix code to

Hi Linus, Here are some 2.6.20 fixes for ocfs2. The patch by Zhen Wei isn't really a fix, but a very small amount of support for a feature which is mostly implemented in ocfs2-tools. Considering it's just a single attribute export via configfs, I'd say it's pretty safe to merge. Please pull from 'upstream-linus' branch of

...t3_find_entry (old_dentry, &old_de); + old_bh = ext3_find_entry (old_dir, &old_dentry->d_name, &old_de); /* * Check for inode number is _not_ due to possible IO errors. * We might rmdir the source, keep it as pwd of some process @@ -2190,7 +2187,7 @@ goto end_rename; new_inode = new_dentry->d_inode; - new_bh = ext3_find_entry (new_dentry, &new_de); + new_bh = ext3_find_entry (new_dir, &new_dentry->d_name, &new_de); if (new_bh) { if (!new_inode) { brelse (new_bh); @@ -2253,7 +2250,7 @@ struct buffer_head *old_bh2; struct ext3_dir_entry_2...

Hi all, So I have finally finished the v1 of reflink for ocfs2. It has some bugs that I am still investigating, but the schema is almost there. So I'd like to send it out first for review. And Tristan and I will continue to work on the stability of the code. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please

Hi all, Change from v1 to v2: bug fix and metadata/credits reservation improvement. The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink. For the design doc, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/RefcountTrees http://oss.oracle.com/osswiki/OCFS2/DesignDocs/ReflinkOperation

...nel: [<ffffffff81071e27>] ? warn_slowpath_common+0x87/0xc0 Mar 5 11:41:46 chadwick kernel: [<ffffffff81071f16>] ? warn_slowpath_fmt+0x46/0x50 Mar 5 11:41:46 chadwick kernel: [<ffffffff812944ed>] ? __list_add+0x6d/0xa0 Mar 5 11:41:46 chadwick kernel: [<ffffffff811a6c02>] ? new_inode+0x72/0xb0 Mar 5 11:41:46 chadwick kernel: [<ffffffffa03f45d5>] ? gfs2_create_inode+0x1b5/0x1150 [gfs2] Mar 5 11:41:46 chadwick kernel: [<ffffffffa03f3986>] ? gfs2_glock_nq_init+0x16/0x40 [gfs2] Mar 5 11:41:46 chadwick kernel: [<ffffffffa03ffc74>] ? gfs2_mkdir+0x24/0x30 [gfs2]...

Hi all, So I have finally finished the v3 of reflink for ocfs2. The biggest change is that we support 64bit cluster offset now(Thank Mark and Joel for it). [View] http://oss.oracle.com/git/?p=tma/linux-2.6.git;a=shortlog;h=refcount [Pull] git://oss.oracle.com/git/tma/linux-2.6.git refcount The general information for reflink, please see http://oss.oracle.com/osswiki/OCFS2/DesignDocs/Reflink.

The following patches implement indexed directory support in Ocfs2, mostly according to the design doc I wrote up a while ago: http://oss.oracle.com/osswiki/OCFS2/DesignDocs/IndexedDirectories The patches have been rebased on top of 2.6.29-rc2. It should be trivial to put them into merge_window. Things are what I'd call complete now. I'd like to get these into the merge_window branch

...this.name = name; > this.len = strlen(name); > this.hash = 0; > sb = movable_mnt.mnt_sb; > patch.denty = d_alloc_pseudo(movable_inode_mnt->mnt_sb, &this); > patch.mnt = mntget(movable_inode_mnt); > > inode = new_inode(sb); > .. > .. > inode->i_mapping->a_ops = a_ops; > d_instantiate(path.dentry, inode); > > return alloc_file(&path, FMODE_WRITE | FMODE_READ, f_op); > } > > And in our driver, we can change vma->vm_file with new one....

...this.name = name; > this.len = strlen(name); > this.hash = 0; > sb = movable_mnt.mnt_sb; > patch.denty = d_alloc_pseudo(movable_inode_mnt->mnt_sb, &this); > patch.mnt = mntget(movable_inode_mnt); > > inode = new_inode(sb); > .. > .. > inode->i_mapping->a_ops = a_ops; > d_instantiate(path.dentry, inode); > > return alloc_file(&path, FMODE_WRITE | FMODE_READ, f_op); > } > > And in our driver, we can change vma->vm_file with new one....

...er. But the problem with this is that we don't have directory dentries in ocfs2_rename(). Hopefully obtaining them via i_dentry should be possible but I'm not completely certain about interactions with bind mounts etc... 2) ocfs2_rename() also first locks old_inode (to unlink it) and then new_inode (to create new link to it). Now in the directory structure where are files 'a' and 'b' linked to two directories 'd1' and 'd2', there can be two renames racing against each other. One does 'mv d1/a d1/b' the other does 'mv d2/b d2/a'. Again, they try...

Found 15 patches (out of 162) that appeared relevant to ocfs2 1.4. Please review. Sunil

...@ static int eventpollfs_delete_dentry(str -static struct inode *ep_eventpoll_inode(void) -+static struct inode *ep_eventpoll_inode(struct file_operations *fops) ++static struct inode *ep_eventpoll_inode(const struct file_operations *fops) { int error = -ENOMEM; struct inode *inode = new_inode(eventpoll_mnt->mnt_sb); @@ -288,7 +288,7 @@ static inline void eventpoll_release(str + */ +struct eventpoll; +int ep_getfd(int *efd, struct inode **einode, struct file **efile, -+ struct eventpoll *ep, struct file_operations *fops); ++ struct eventpoll *ep, const stru...

On 06/16/2016 11:07 AM, Minchan Kim wrote: > On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote: >> On 06/16/2016 05:56 AM, Minchan Kim wrote: >>> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: >>>> On 06/15/2016 08:02 AM, Minchan Kim wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jun 13, 2016 at

On 06/16/2016 11:07 AM, Minchan Kim wrote: > On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote: >> On 06/16/2016 05:56 AM, Minchan Kim wrote: >>> On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: >>>> On 06/15/2016 08:02 AM, Minchan Kim wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jun 13, 2016 at

Hi, The following patches comprise the bulk of Ocfs2 updates for the 2.6.30 merge window. Aside from larger, more involved fixes, we're adding the following features, which I will describe in the order their patches are mailed. Sunil's exported some more state to our debugfs files, and consolidated some other aspects of our debugfs infrastructure. This will further aid us in debugging