Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1357793 > unrolled thread

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

Started byStephen Rothwell <sfr@canb.auug.org.au>
First post2016-03-15 05:10 +0100
Last post2016-03-15 14:20 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

Contents

  linux-next: manual merge of the aio tree with the vfs tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-15 05:10 +0100
    Re: linux-next: manual merge of the aio tree with the vfs tree Al Viro <viro@ZenIV.linux.org.uk> - 2016-03-15 05:40 +0100
      Re: linux-next: manual merge of the aio tree with the vfs tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-03-15 06:00 +0100
      Re: linux-next: manual merge of the aio tree with the vfs tree Al Viro <viro@ZenIV.linux.org.uk> - 2016-03-15 06:10 +0100
        Re: linux-next: manual merge of the aio tree with the vfs tree Al Viro <viro@ZenIV.linux.org.uk> - 2016-03-15 06:20 +0100
          Re: linux-next: manual merge of the aio tree with the vfs tree Benjamin LaHaise <bcrl@kvack.org> - 2016-03-15 14:20 +0100

#1357793 — linux-next: manual merge of the aio tree with the vfs tree

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-03-15 05:10 +0100
Subjectlinux-next: manual merge of the aio tree with the vfs tree
Message-ID<rcOsV-5fI-3@gated-at.bofh.it>
Hi Ben,

Today's linux-next merge of the aio tree got a conflict in:

  fs/namei.c

between commit:

  5955102c9984 ("wrappers for ->i_mutex access")

from the vfs tree and commit:

  5d3d80fcf992 ("aio: add support for in-submit openat")

from the aio tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc fs/namei.c
index 794f81dce766,260782f5a868..000000000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -3125,9 -3079,15 +3125,15 @@@ retry_lookup
  		 * dropping this one anyway.
  		 */
  	}
+ 
+ 	if (nd->flags & LOOKUP_NONBLOCK) {
+ 		error = -EAGAIN;
+ 		goto out;
+ 	}
+ 		
 -	mutex_lock(&dir->d_inode->i_mutex);
 +	inode_lock(dir->d_inode);
  	error = lookup_open(nd, &path, file, op, got_write, opened);
 -	mutex_unlock(&dir->d_inode->i_mutex);
 +	inode_unlock(dir->d_inode);
  
  	if (error <= 0) {
  		if (error)

[toc] | [next] | [standalone]

#1357803

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-03-15 05:40 +0100
Message-ID<rcOVY-5tH-19@gated-at.bofh.it>
In reply to#1357793
On Tue, Mar 15, 2016 at 03:06:40PM +1100, Stephen Rothwell wrote:
> Hi Ben,
> 
> Today's linux-next merge of the aio tree got a conflict in:
> 
>   fs/namei.c
> 
> between commit:
> 
>   5955102c9984 ("wrappers for ->i_mutex access")
> 
> from the vfs tree and commit:
> 
>   5d3d80fcf992 ("aio: add support for in-submit openat")
> 
> from the aio tree.

What.

The.

Hell?

The first commit is in the mainline, not in vfs tree.  And it had been
there since before -rc1.

Incidentally, why the hell has that thing never landed in my mailbox?  Not
directly, not Cc'd, not via fsdevel either.

Ben, what the fuck going on?  OK, you don't feel necessary to mention
that to me (or have me take a look through it).  Your business.  You also
don't bother to bring it on fsdevel.  Again, your estimates of the
usefulness of said list and review there are your business.  But it looks
like you also do not bother to check what has landed in the mainline two
months ago.  WTF?

[toc] | [prev] | [next] | [standalone]

#1357804

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-03-15 06:00 +0100
Message-ID<rcPfj-5BF-1@gated-at.bofh.it>
In reply to#1357803
Hi Al,

On Tue, 15 Mar 2016 04:34:48 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> > between commit:
> > 
> >   5955102c9984 ("wrappers for ->i_mutex access")
> > 
> > from the vfs tree and commit:
> 
> What.
> 
> The.
> 
> Hell?
> 
> The first commit is in the mainline, not in vfs tree.  And it had been
> there since before -rc1.

Sorry, my mistake.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1357806

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-03-15 06:10 +0100
Message-ID<rcPoZ-5Wk-5@gated-at.bofh.it>
In reply to#1357803
On Tue, Mar 15, 2016 at 04:34:48AM +0000, Al Viro wrote:

> Incidentally, why the hell has that thing never landed in my mailbox?  Not
> directly, not Cc'd, not via fsdevel either.
> 
> Ben, what the fuck going on?  OK, you don't feel necessary to mention
> that to me (or have me take a look through it).  Your business.  You also
> don't bother to bring it on fsdevel.  Again, your estimates of the
> usefulness of said list and review there are your business.  But it looks
> like you also do not bother to check what has landed in the mainline two
> months ago.  WTF?

While we are at it, aio.git commit in question is crap anyway.  What is the
semantics of that LOOKUP_NONBLOCK thing and what makes you think that
it will *not* block prior to reaching do_last()?  LOOKUP_RCU that was
originally there?  Sorry, wrong.  RCU pathwalk will happily fall back to
non-RCU one if it can do so without restart from scratch.  And proceed
to lock directories, hit the disk over nbd over wet string, do automounts,
etc.  Anything and everything.  IOW, this is complete BS and had been such
for at least ~5 years.

There *is* a reason for code review.  Or, at least, asking somebody familiar
with the code you are working with whether some assumption you are making
is true or false.  Me, for example, in our conversation regarding earlier parts
of aio.git queue about a week ago.  Or at any other point.

						Al "Really annoyed" Viro

[toc] | [prev] | [next] | [standalone]

#1357807

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-03-15 06:20 +0100
Message-ID<rcPyF-5ZN-1@gated-at.bofh.it>
In reply to#1357806
On Tue, Mar 15, 2016 at 05:07:12AM +0000, Al Viro wrote:

> There *is* a reason for code review.  Or, at least, asking somebody familiar
> with the code you are working with whether some assumption you are making
> is true or false.  Me, for example, in our conversation regarding earlier parts
> of aio.git queue about a week ago.  Or at any other point.

While we are at it, 150a0b49 ("aio: add support for async openat()") is also
crap.  fs_struct and files_struct is nowhere near enough.  And yes, I realize
that your application probably doesn't step into it.  Which means that these
patches are just fine for your private kernel.  _Not_ for mainline.

Reviewed-and-NAKed-by: Al Viro <viro@zeniv.linux.org.uk>

[toc] | [prev] | [next] | [standalone]

#1358034

FromBenjamin LaHaise <bcrl@kvack.org>
Date2016-03-15 14:20 +0100
Message-ID<rcX3b-2zA-3@gated-at.bofh.it>
In reply to#1357807
On Tue, Mar 15, 2016 at 05:19:39AM +0000, Al Viro wrote:
> On Tue, Mar 15, 2016 at 05:07:12AM +0000, Al Viro wrote:
> 
> > There *is* a reason for code review.  Or, at least, asking somebody familiar
> > with the code you are working with whether some assumption you are making
> > is true or false.  Me, for example, in our conversation regarding earlier parts
> > of aio.git queue about a week ago.  Or at any other point.
> 
> While we are at it, 150a0b49 ("aio: add support for async openat()") is also
> crap.  fs_struct and files_struct is nowhere near enough.  And yes, I realize
> that your application probably doesn't step into it.  Which means that these
> patches are just fine for your private kernel.  _Not_ for mainline.
> 
> Reviewed-and-NAKed-by: Al Viro <viro@zeniv.linux.org.uk>

You've had two months to make this comment, so I'm glad you've finally 
done so.

		-ben
-- 
"Thought is the essence of where you are now."

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web