Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Arnd, On Wed, 18 May 2016 16:25:39 +0200 Arnd Bergmann wrote: > > I'm getting a warning here because the 'offset' variable is no longer > used, I've fixed it up on my test box like this: Thanks. I have applied that to linux-next today and fixed up the merge fix patch from

Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Arnd, On Wed, 18 May 2016 16:25:39 +0200 Arnd Bergmann wrote: > > I'm getting a warning here because the 'offset' variable is no longer > used, I've fixed it up on my test box like this: Thanks. I have applied that to linux-next today and fixed up the merge fix patch from tomorrow. >

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tuesday 17 May 2016 10:23:55 Stephen Rothwell wrote: > ++static ssize_t ext4_direct_IO_read(struct kiocb *iocb, struct iov_iter > *iter) > +{ > + int unlocked = 0; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > ++ loff_t offset = iocb->ki_pos; > + ssize_t

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tuesday 17 May 2016 10:23:55 Stephen Rothwell wrote: > ++static ssize_t ext4_direct_IO_read(struct kiocb *iocb, struct iov_iter > *iter) > +{ > + int unlocked = 0; > + struct inode *inode = iocb->ki_filp->f_mapping->host; > ++ loff_t offset = iocb->ki_pos; > + ssize_t

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, May 17, 2016 at 10:23:55AM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the vfs tree got conflicts in: > > fs/ext4/ext4.h > fs/ext4/indirect.c > fs/ext4/inode.c > > between commit: > > 914f82a32d02 ("ext4: refactor direct IO code") > > from the ext4

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, May 17, 2016 at 10:23:55AM +1000, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the vfs tree got conflicts in: > > fs/ext4/ext4.h > fs/ext4/indirect.c > fs/ext4/inode.c > > between commit: > > 914f82a32d02 ("ext4: refactor direct IO code") > > from the ext4

linux-next: manual merge of the vfs tree with the ext4 tree

Hi all, Today's linux-next merge of the vfs tree got conflicts in: fs/ext4/ext4.h fs/ext4/indirect.c fs/ext4/inode.c between commit: 914f82a32d02 ("ext4: refactor direct IO code") from the ext4 tree and commit: c8b8e32d700f ("direct-io: eliminate the offset argument to

linux-next: manual merge of the vfs tree with the ext4 tree

Hi all, Today's linux-next merge of the vfs tree got conflicts in: fs/ext4/ext4.h fs/ext4/indirect.c fs/ext4/inode.c between commit: 914f82a32d02 ("ext4: refactor direct IO code") from the ext4 tree and commit: c8b8e32d700f ("direct-io: eliminate the offset argument to

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode") from the ext4 tree and commit 680baacbca69 ("new ->follow_link() and ->put_link() calling conventions") from the vfs tree. I

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit b7236e21d55f (ext4 crypto: reorganize how we store keys in the inode) from the ext4 tree and commit 680baacbca69 (new -follow_link() and -put_link() calling conventions) from the vfs tree. I fixed

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit fd64e6fd4575 ("ext4 crypto: reorganize how we store keys in the inode") from the ext4 tree and commits 5542f03602af ("ext4: split inode_operations for encrypted symlinks off the rest") and

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit fd64e6fd4575 (ext4 crypto: reorganize how we store keys in the inode) from the ext4 tree and commits 5542f03602af (ext4: split inode_operations for encrypted symlinks off the rest) and cf41cea5a829

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit 48e72c7a0127 ("ext4 crypto: Add symlink encryption") from the ext4 tree and commit 5dd3dc06371a ("VFS: normal filesystems (and lustre): d_inode() annotations") from the vfs tree. [The ext4 tree

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 05:02:15PM -0400, Theodore Ts'o wrote: > On Tue, Apr 14, 2015 at 06:17:43PM +0100, Al Viro wrote: > > Except that you do not handle the slow unencrypted case - you end up with > > kfree() on the freshly kunmaped address. > > Ah, right, we're actually kmalloc'ing the space

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 06:17:43PM +0100, Al Viro wrote: > Except that you do not handle the slow unencrypted case - you end up with > kfree() on the freshly kunmaped address. Ah, right, we're actually kmalloc'ing the space that case as well --- so hanging on the cpage is pointless; which was the

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 06:18:41PM +0200, Christoph Hellwig wrote: > Also for something that while only > implemented in one filesystem has pretty broad API implications I'd > really expect a generalist VFS review (I plan to get to it ASAP..). There really isn't much of an API. We have an ioctl

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 01:00:00PM -0400, Theodore Ts'o wrote: > > Look, either nd_get_link() points inside that page (in which case that > > kfree() is obviously invalid), or it points at kmalloc'ed buffer. In > > which case kfree() is correct, but WTF do you need anything _else_? > > Such as

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 02:48:55AM +0100, Al Viro wrote: > On Tue, Apr 14, 2015 at 11:30:25AM +1000, Stephen Rothwell wrote: > > +static void ext4_put_link(struct dentry *dentry, struct nameidata *nd, > > +void *cookie) > > +{ > > + struct page *page = cookie; > > + char

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 11:26:46PM -0400, Theodore Ts'o wrote: > On Tue, Apr 07, 2015 at 09:02:14AM +0200, Christoph Hellwig wrote: > > FYI, the ext4 tree seems to have the crypto support, which I don't think is > > ready for 4.1 with all the implications of it.. > > What sort of implications are

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 01:00:00PM -0400, Theodore Ts'o wrote: Look, either nd_get_link() points inside that page (in which case that kfree() is obviously invalid), or it points at kmalloc'ed buffer. In which case kfree() is correct, but WTF do you need anything _else_? Such as mapped

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 02:48:55AM +0100, Al Viro wrote: On Tue, Apr 14, 2015 at 11:30:25AM +1000, Stephen Rothwell wrote: +static void ext4_put_link(struct dentry *dentry, struct nameidata *nd, +void *cookie) +{ + struct page *page = cookie; + char *buf =

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 11:26:46PM -0400, Theodore Ts'o wrote: On Tue, Apr 07, 2015 at 09:02:14AM +0200, Christoph Hellwig wrote: FYI, the ext4 tree seems to have the crypto support, which I don't think is ready for 4.1 with all the implications of it.. What sort of implications are you

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit 48e72c7a0127 (ext4 crypto: Add symlink encryption) from the ext4 tree and commit 5dd3dc06371a (VFS: normal filesystems (and lustre): d_inode() annotations) from the vfs tree. [The ext4 tree commit

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 06:18:41PM +0200, Christoph Hellwig wrote: Also for something that while only implemented in one filesystem has pretty broad API implications I'd really expect a generalist VFS review (I plan to get to it ASAP..). There really isn't much of an API. We have an ioctl to

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 05:02:15PM -0400, Theodore Ts'o wrote: On Tue, Apr 14, 2015 at 06:17:43PM +0100, Al Viro wrote: Except that you do not handle the slow unencrypted case - you end up with kfree() on the freshly kunmaped address. Ah, right, we're actually kmalloc'ing the space that

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 06:17:43PM +0100, Al Viro wrote: Except that you do not handle the slow unencrypted case - you end up with kfree() on the freshly kunmaped address. Ah, right, we're actually kmalloc'ing the space that case as well --- so hanging on the cpage is pointless; which was the

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 11:30:25AM +1000, Stephen Rothwell wrote: > +static void ext4_put_link(struct dentry *dentry, struct nameidata *nd, > + void *cookie) > +{ > +struct page *page = cookie; > +char *buf = nd_get_link(nd); > + > +if (page) { > +

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit f1195c72c951 ("ext4 crypto: Add symlink encryption") from the ext4 tree and commit 5dd3dc06371a ("VFS: normal filesystems (and lustre): d_inode() annotations") from the vfs tree. I fixed it up (see

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit f1195c72c951 (ext4 crypto: Add symlink encryption) from the ext4 tree and commit 5dd3dc06371a (VFS: normal filesystems (and lustre): d_inode() annotations) from the vfs tree. I fixed it up (see

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 14, 2015 at 11:30:25AM +1000, Stephen Rothwell wrote: +static void ext4_put_link(struct dentry *dentry, struct nameidata *nd, + void *cookie) +{ +struct page *page = cookie; +char *buf = nd_get_link(nd); + +if (page) { +

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit 8ee224253787 ("ext4 crypto: Add symlink encryption") from the ext4 tree and commit 5dd3dc06371a ("VFS: normal filesystems (and lustre): d_inode() annotations") from the vfs tree. I fixed it up (see

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/namei.c between commits e12fb97222fc ("ext4: make fsync to sync parent dir in no-journal for real this time") and 5c34f02d301e ("ext4 crypto: partial update to namei.c for fname crypto") from the ext4 tree and commit

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/symlink.c between commit 8ee224253787 (ext4 crypto: Add symlink encryption) from the ext4 tree and commit 5dd3dc06371a (VFS: normal filesystems (and lustre): d_inode() annotations) from the vfs tree. I fixed it up (see

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/namei.c between commits e12fb97222fc (ext4: make fsync to sync parent dir in no-journal for real this time) and 5c34f02d301e (ext4 crypto: partial update to namei.c for fname crypto) from the ext4 tree and commit

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 09:02:14AM +0200, Christoph Hellwig wrote: > FYI, the ext4 tree seems to have the crypto support, which I don't think is > ready for 4.1 with all the implications of it.. What sort of implications are you concerned about? We're no longer exposing anything via the xattr

Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Christoph, On Tue, 7 Apr 2015 09:02:14 +0200 Christoph Hellwig wrote: > > On Tue, Apr 07, 2015 at 02:00:35PM +1000, Stephen Rothwell wrote: > > Hi Al, > > > > Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c > > between commit 72b8e0f9fa8a ("ext4: remove unused

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 02:00:35PM +1000, Stephen Rothwell wrote: > Hi Al, > > Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c > between commit 72b8e0f9fa8a ("ext4: remove unused header files") from the > ext4 tree and commit e2e40f2c1ed4 ("fs: move struct kiocb to

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 02:00:35PM +1000, Stephen Rothwell wrote: Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c between commit 72b8e0f9fa8a (ext4: remove unused header files) from the ext4 tree and commit e2e40f2c1ed4 (fs: move struct kiocb to fs.h) from

Re: linux-next: manual merge of the vfs tree with the ext4 tree

Hi Christoph, On Tue, 7 Apr 2015 09:02:14 +0200 Christoph Hellwig h...@lst.de wrote: On Tue, Apr 07, 2015 at 02:00:35PM +1000, Stephen Rothwell wrote: Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c between commit 72b8e0f9fa8a (ext4: remove unused

Re: linux-next: manual merge of the vfs tree with the ext4 tree

On Tue, Apr 07, 2015 at 09:02:14AM +0200, Christoph Hellwig wrote: FYI, the ext4 tree seems to have the crypto support, which I don't think is ready for 4.1 with all the implications of it.. What sort of implications are you concerned about? We're no longer exposing anything via the xattr

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c between commit 72b8e0f9fa8a ("ext4: remove unused header files") from the ext4 tree and commit e2e40f2c1ed4 ("fs: move struct kiocb to fs.h") from the vfs tree. I fixed it up (see below) and can carry the fix as

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/inode.c between commit 72b8e0f9fa8a (ext4: remove unused header files) from the ext4 tree and commit e2e40f2c1ed4 (fs: move struct kiocb to fs.h) from the vfs tree. I fixed it up (see below) and can carry the fix as

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/file.c between commit 00532604c72e ("ext4: introduce new i_write_mutex to protect fallocate") from the ext4 tree and commit 9b884164d597 ("convert ext4 to ->write_iter()") from the vfs tree. I fixed it up (see below) and

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/file.c between commit 00532604c72e (ext4: introduce new i_write_mutex to protect fallocate) from the ext4 tree and commit 9b884164d597 (convert ext4 to -write_iter()) from the vfs tree. I fixed it up (see below) and can

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/file.c between rebased commits from the ext4 tree and commit 29a8196bc41c ("convert ext4 to ->write_iter()") from the vfs tree. I fixed it up (in this case I used the conflicting hunks from the vfs tree - I hope its right)

linux-next: manual merge of the vfs tree with the ext4 tree

Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/file.c between rebased commits from the ext4 tree and commit 29a8196bc41c (convert ext4 to -write_iter()) from the vfs tree. I fixed it up (in this case I used the conflicting hunks from the vfs tree - I hope its right)