From: Al Viro <viro@zeniv.linux.org.uk>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK
Date: Mon, 4 Jan 2021 16:54:30 +0000 [thread overview]
Message-ID: <20210104165430.GI3579531@ZenIV.linux.org.uk> (raw)
In-Reply-To: <a51a2db9-716a-be20-5f71-5180394a992b@kernel.dk>
On Mon, Jan 04, 2021 at 07:43:17AM -0700, Jens Axboe wrote:
> > I've not put it into #for-next yet; yell if you see any problems with that
> > branch, or it'll end up there ;-)
>
> Thanks Al - but you picked out of v3, not v4. Not that there are huge
> changes between the two, from the posting of v4:
>
> - Rename LOOKUP_NONBLOCK -> LOOKUP_CACHED, and ditto for the RESOLVE_
> flag. This better explains what the feature does, making it more self
> explanatory in terms of both code readability and for the user visible
> part.
>
> - Remove dead LOOKUP_NONBLOCK check after we've dropped LOOKUP_RCU
> already, spotted by Al.
>
> - Add O_TMPFILE to the checks upfront, so we can drop the checking in
> do_tmpfile().
>
> and it sounds like you did the last two when merging yourself.
Yes - back when I'd posted that review.
> I do like
> LOOKUP_CACHED better than LOOKUP_NONBLOCK, mostly for the externally
> self-documenting feature of it. What do you think?
Agreed, especially since _NONBLOCK would confuse users into assumption
that operation is actually non-blocking...
> Here's the v4 posting, fwiw:
>
> https://lore.kernel.org/linux-fsdevel/20201217161911.743222-1-axboe@kernel.dk/
Sorry, picked from the local branch that sat around since Mid-December ;-/
Fixed. Another change: ..._child part in unlazy_child() is misleading -
it might as well be used for .. traversal, where dentry is usually the
_parent_ of nd->path.dentry. The real constraint here is that dentry/seq pair
had been valid next position at some point during the RCU walk. Renamed to
try_to_unlazy_next(), (hopefully) fixed the comment...
Updated variant force-pushed.
next prev parent reply other threads:[~2021-01-04 16:55 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-14 19:13 [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Jens Axboe
2020-12-14 19:13 ` [PATCH 1/4] fs: make unlazy_walk() error handling consistent Jens Axboe
2020-12-14 19:13 ` [PATCH 2/4] fs: add support for LOOKUP_NONBLOCK Jens Axboe
2020-12-15 12:24 ` Matthew Wilcox
2020-12-15 15:29 ` Jens Axboe
2020-12-15 15:33 ` Matthew Wilcox
2020-12-15 15:37 ` Jens Axboe
2020-12-15 16:08 ` Jens Axboe
2020-12-15 16:14 ` Jens Axboe
2020-12-15 18:29 ` Linus Torvalds
2020-12-15 18:44 ` Jens Axboe
2020-12-15 18:47 ` Linus Torvalds
2020-12-15 19:03 ` Jens Axboe
2020-12-15 19:32 ` Linus Torvalds
2020-12-15 19:38 ` Jens Axboe
2020-12-16 2:36 ` Al Viro
2020-12-16 3:30 ` Jens Axboe
2020-12-16 2:43 ` Al Viro
2020-12-16 3:32 ` Jens Axboe
2020-12-14 19:13 ` [PATCH 3/4] fs: expose LOOKUP_NONBLOCK through openat2() RESOLVE_NONBLOCK Jens Axboe
2020-12-15 22:25 ` Dave Chinner
2020-12-15 22:31 ` Linus Torvalds
2020-12-15 23:25 ` Jens Axboe
2020-12-16 2:37 ` Al Viro
2020-12-16 3:39 ` Linus Torvalds
2020-12-14 19:13 ` [PATCH 4/4] io_uring: enable LOOKUP_NONBLOCK path resolution for filename lookups Jens Axboe
2020-12-15 3:06 ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK Linus Torvalds
2020-12-15 3:18 ` Jens Axboe
2020-12-15 6:11 ` Al Viro
2020-12-15 15:29 ` Jens Axboe
2021-01-04 5:31 ` Al Viro
2021-01-04 14:43 ` Jens Axboe
2021-01-04 16:54 ` Al Viro [this message]
2021-01-04 17:03 ` Jens Axboe
[not found] ` <m1lfbrwrgq.fsf@fess.ebiederm.org>
2021-02-14 16:38 ` [PATCHSET v3 0/4] fs: Support for LOOKUP_NONBLOCK / RESOLVE_NONBLOCK (Insufficiently faking current?) Jens Axboe
2021-02-14 20:30 ` Linus Torvalds
2021-02-14 21:24 ` Al Viro
2021-02-15 18:07 ` Eric W. Biederman
2021-02-15 18:24 ` Jens Axboe
2021-02-15 21:09 ` Jens Axboe
2021-02-15 22:41 ` Eric W. Biederman
2021-02-16 2:41 ` Jens Axboe
2021-02-17 1:18 ` Jens Axboe
2021-02-17 1:26 ` Jens Axboe
2021-02-17 3:11 ` Jens Axboe
2021-02-15 17:56 ` Eric W. Biederman
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=20210104165430.GI3579531@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=linux-fsdevel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.