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.
> commit
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
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
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 ->direct_IO")
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 f
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 cf41cea5a8
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 comm
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 t
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
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 t
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 ma
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
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
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) {
> +
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
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
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 5dd3dc0
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 int
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 head
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.
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
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 ca
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)
23 matches
Mail list logo
