linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs fixes
Date: Mon, 3 Apr 2017 01:30:45 +0100	[thread overview]
Message-ID: <20170403003045.GK29622@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFwxjEjV++j-WRXomZrjBR6Dhx9nM-SOwM7pD=zCnMspKQ@mail.gmail.com>

On Sun, Apr 02, 2017 at 05:10:08PM -0700, Linus Torvalds wrote:
> On Sun, Apr 2, 2017 at 4:59 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Sun, Apr 2, 2017 at 10:01 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >>         statx followup fixes, fix for a nasty corner case in path_init()
> >> leaving path.dentry in RCU mode pointing to a dentry without DCACHE_RCUACCESS
> >> and a fix for stack-smashing on alpha.
> >
> > These were apparently committed minutes before sending me the pull request.
> >
> > Why? What kind of testing did this all get?
> 
> Also, that RCU fix really stinks. It makes no sense. Any valid base
> for actual pathname lookup will already have the bit set, so the only
> issue is when people play games and use a non-path file descriptor
> without a pathname. Right?
> 
> And that case shouldn't actually use RCU lookup AT ALL!
> 
> By definition such a case will  just be immediately unlazied anyway in
> complete_walk(), so doing an RCU lookup on an empty path only adds
> overhead, and there is no actual point in doing an RCU walk on an
> empty pathname.
> 
> So I get the feeling that the proper fix would be just something like
> 
>       /* Don't RCU-lookup empty pathnames */
>       if ((flags & LOOKUP_RCU) && !*s)
>             flags &= ~LOOKUP_RCU;
> 
> at the very top of path_init(), which
> 
>  (a) makes the code more efficiant, since we don't do those
> unnecessary games with sequence numbers and RCU locking only to un-RCU
> it immedately
> 
> and
> 
>  (b) obviates the need for those DCACHE_RCUACCESS games entirely,
> since anything that can actually be used as a base for pathname lookup
> will already have that bit set, afaik.

Currently true and almost certainly will remain so.  Point taken, what you
are suggesting is better.  Actually, the invariant to watch for is
"no d_can_lookup() withtout DCACHE_RCUACCESS" and that we can trivially
enforce by one-liner change in d_flags_for_inode() -
s/DCACHE_DIRECTORY_TYPE/& | DCACHE_RCUACCESS/

OK...

  reply	other threads:[~2017-04-03  0:30 UTC|newest]

Thread overview: 113+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-02 17:01 [git pull] vfs fixes Al Viro
2017-04-02 23:59 ` Linus Torvalds
2017-04-03  0:10   ` Linus Torvalds
2017-04-03  0:30     ` Al Viro [this message]
2017-04-03  0:43       ` Al Viro
2017-04-03  0:58         ` Linus Torvalds
2017-04-03  2:21           ` Al Viro
2017-04-03  6:00             ` Eric W. Biederman
2017-04-03  7:46               ` Al Viro
2017-04-04  0:22               ` Ian Kent
2017-04-04  0:47               ` Ian Kent
2017-04-03  0:20   ` Al Viro
  -- strict thread matches above, loose matches on Subject: below --
2024-04-26 14:59 [GIT PULL] " Christian Brauner
2024-04-26 18:09 ` pr-tracker-bot
2024-04-05 11:22 Christian Brauner
2024-04-05 17:09 ` pr-tracker-bot
2024-03-18 12:19 Christian Brauner
2024-03-18 16:48 ` pr-tracker-bot
2024-03-18 19:14 ` Linus Torvalds
2024-03-18 19:41   ` Linus Torvalds
2024-03-19  6:58     ` Christian Brauner
2024-03-20 10:21       ` Christian Brauner
2024-03-06 15:45 Christian Brauner
2024-03-06 16:33 ` pr-tracker-bot
2024-03-01 12:45 Christian Brauner
2024-03-01 20:37 ` pr-tracker-bot
2024-02-22 14:03 Christian Brauner
2024-02-22 18:18 ` pr-tracker-bot
2024-02-12 13:00 Christian Brauner
2024-02-12 17:03 ` pr-tracker-bot
2024-01-13 12:31 Christian Brauner
2024-01-17 20:03 ` pr-tracker-bot
2023-11-24 10:27 Christian Brauner
2023-11-24 18:25 ` Linus Torvalds
2023-11-24 18:52   ` Linus Torvalds
2023-11-24 20:12     ` Linus Torvalds
2023-11-25 13:05       ` Christian Brauner
2023-11-25 13:10   ` Christian Brauner
2023-11-25 13:28     ` Omar Sandoval
2023-11-25 14:04       ` Christian Brauner
2023-11-24 18:26 ` pr-tracker-bot
2023-10-19 10:07 Christian Brauner
2023-10-19 16:37 ` Linus Torvalds
2023-10-20 11:14   ` Christian Brauner
2023-10-19 18:36 ` pr-tracker-bot
2023-09-26 10:39 Christian Brauner
2023-09-26 16:14 ` pr-tracker-bot
2023-07-06 11:52 Christian Brauner
2023-07-07  2:27 ` pr-tracker-bot
2023-07-02 11:28 Christian Brauner
2023-07-02 18:53 ` pr-tracker-bot
2023-05-25 12:22 Christian Brauner
2023-05-25 18:18 ` pr-tracker-bot
2023-05-12 15:31 Christian Brauner
2023-05-12 22:14 ` pr-tracker-bot
2023-04-03 11:04 Christian Brauner
2023-04-03 16:51 ` pr-tracker-bot
2023-03-12 12:18 Christian Brauner
2023-03-12 16:20 ` pr-tracker-bot
2020-09-22 21:29 [git pull] " Al Viro
2020-09-22 22:15 ` pr-tracker-bot
     [not found] <CAHk-=wgdsv1UA+QtgiJM8KQAG7N7_9iK_edchnzZYyj+nxmfLA@mail.gmail.com>
     [not found] ` <20200113195448.GT8904@ZenIV.linux.org.uk>
     [not found]   ` <CAHk-=whn5qk-e-KnYr6HNe5hp45v+XyDbsA2+szXvK3gC06A2w@mail.gmail.com>
2020-01-15  6:41     ` Al Viro
2020-01-15 19:35       ` pr-tracker-bot
2018-04-20 15:58 Al Viro
2018-04-20 18:29 ` Andrew Morton
2018-04-20 19:09   ` Al Viro
2018-04-20 19:57     ` Andrew Morton
2017-06-17  2:56 Al Viro
2017-04-09  5:40 Al Viro
2017-04-11  6:10 ` Linus Torvalds
2017-04-11  6:48   ` Al Viro
2017-04-11 21:02     ` Andreas Dilger
2017-04-12  7:00       ` Linus Torvalds
2017-04-15  6:41 ` Vegard Nossum
2017-04-15 16:51   ` Linus Torvalds
2017-04-15 17:08     ` Al Viro
     [not found] <13136.1466196630@jrobl>
     [not found] ` <20160617221614.GE14480@ZenIV.linux.org.uk>
     [not found]   ` <2123.1466313884@jrobl>
     [not found]     ` <20160619165557.GH14480@ZenIV.linux.org.uk>
     [not found]       ` <28627.1466397254@jrobl>
     [not found]         ` <20160620053530.GI14480@ZenIV.linux.org.uk>
     [not found]           ` <20160620145125.GL14480@ZenIV.linux.org.uk>
2016-06-20 17:14             ` Al Viro
2016-06-08  2:12 Al Viro
2016-05-28  0:10 Al Viro
2016-02-28  1:09 Al Viro
2014-09-14 19:47 Al Viro
2014-09-26 20:38 ` Joachim Eastwood
2014-09-26 20:46 ` Joachim Eastwood
2014-09-26 20:58   ` Al Viro
2014-09-26 21:28     ` Joachim Eastwood
2014-09-26 21:52       ` Joachim Eastwood
2014-03-24 22:58 Imre Deak
2014-03-25  7:21 ` Sedat Dilek
2014-03-23  7:16 Al Viro
2014-03-23 10:57 ` Sedat Dilek
2014-03-23 15:35   ` Al Viro
2014-03-23 16:56     ` Al Viro
2014-03-23 16:36 ` Linus Torvalds
2014-03-23 16:45   ` Al Viro
2014-03-23 17:01     ` Linus Torvalds
2014-03-24  8:52       ` Sedat Dilek
2014-03-25  0:46         ` Linus Torvalds
2014-03-26 16:36           ` Sedat Dilek
2014-03-26 20:55             ` Linus Torvalds
2014-03-27  6:14               ` Sedat Dilek
2014-03-30 20:33               ` Al Viro
2014-03-30 20:55                 ` Al Viro
2014-03-30 22:39                   ` Linus Torvalds
2014-03-30 23:21                     ` Al Viro
2013-06-22  7:16 Al Viro
2013-03-27  0:36 Al Viro
2012-03-10 21:30 Al Viro
2012-03-10 21:49 ` Linus Torvalds
2012-03-10 22:14   ` Al Viro
2010-01-29  2:39 Al Viro
2010-01-17  7:57 Al Viro
2008-08-25  5:25 Al Viro
2008-08-25  5:29 ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170403003045.GK29622@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).