From: Jens Axboe <[email protected]>
To: Linus Torvalds <[email protected]>,
Al Viro <[email protected]>
Cc: io-uring <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [GIT PULL] io_uring fixes for 5.10-rc
Date: Fri, 20 Nov 2020 19:41:30 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHk-=wimYoUtY4ygMNknkKZHqgYBZbkU4Koo5cE6ar8XjHkzGg@mail.gmail.com>
On 11/20/20 5:23 PM, Linus Torvalds wrote:
> On Fri, Nov 20, 2020 at 1:36 PM Jens Axboe <[email protected]> wrote:
>>
>> I don't disagree with you on that. I've been a bit gun shy on touching
>> the VFS side of things, but this one isn't too bad. I hacked up a patch
>> that allows io_uring to do LOOKUP_RCU and a quick test seems to indicate
>> it's fine. On top of that, we just propagate the error if we do fail and
>> get rid of that odd retry loop.
>
> Ok, this looks better to me (but is obviously not 5.10 material).
>
> That said, I think I'd prefer to keep 'struct nameidata' internal to
> just fs/namei.c, and maybe we can just expert that
>
> struct nameidata nd;
>
> set_nameidata(&nd, req->open.dfd, req->open.filename);
> file = path_openat(&nd, &op, op.lookup_flags | LOOKUP_RCU);
> restore_nameidata();
> return filp == ERR_PTR(-ECHILD) ? -EAGAIN : filp;
>
> as a helper from namei.c instead? Call it "do_filp_open_rcu()" or something?
Yes, that's probably a better idea. I'll move in that direction.
> That "force_nonblock" test seems a bit off, though. Why is that RCU
> case only done when "!force_nonblock"? It would seem that if
> force_nonblock is set, you want to do this too?
Taking a second look at it, it's inverted. So if force_nonblock == true,
we want to do just the RCU lookup.
But I think the bit that you're missing is that the other case will do
the normal lookup, which does an RCU lookup first. It looks needs to
look like this:
if (force_nonblock)
file = do_filp_open_rcu();
else
file = do_filp_open();
--
Jens Axboe
next prev parent reply other threads:[~2020-11-21 2:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 18:45 [GIT PULL] io_uring fixes for 5.10-rc Jens Axboe
2020-11-20 20:02 ` Linus Torvalds
2020-11-20 21:36 ` Jens Axboe
2020-11-21 0:23 ` Linus Torvalds
2020-11-21 2:41 ` Jens Axboe [this message]
2020-11-21 3:00 ` Jens Axboe
2020-11-21 18:07 ` Linus Torvalds
2020-11-21 22:58 ` Jens Axboe
2020-12-10 17:32 ` namei.c LOOKUP_NONBLOCK (was "Re: [GIT PULL] io_uring fixes for 5.10-rc") Jens Axboe
2020-12-10 18:55 ` Linus Torvalds
2020-12-10 19:21 ` Jens Axboe
2020-11-21 0:29 ` [GIT PULL] io_uring fixes for 5.10-rc pr-tracker-bot
-- strict thread matches above, loose matches on Subject: below --
2020-11-27 20:47 Jens Axboe
2020-11-27 21:21 ` pr-tracker-bot
2020-11-13 21:18 Jens Axboe
2020-11-14 0:15 ` pr-tracker-bot
2020-11-07 20:13 Jens Axboe
2020-11-07 22:08 ` pr-tracker-bot
2020-10-30 17:09 Jens Axboe
2020-10-30 22:10 ` pr-tracker-bot
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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