lkml.org 
[lkml]   [2022]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 01/10] VFS: support parallel updates in the one directory.
Date
On Sun, 04 Sep 2022, Al Viro wrote:
> On Sat, Sep 03, 2022 at 03:12:26AM +0100, Al Viro wrote:
>
> > Very much so. You are starting to invent new rules for ->lookup() that
> > just never had been there, basing on nothing better than a couple of
> > examples. They are nowhere near everything there is.
>
> A few examples besides NFS and autofs:

Hi Al,
thanks for these - very helpful. I will give them due consideration
when I write relevant documentation to include in the next posting of
the series.

Thanks a lot,
NeilBrown


>
> ext4, f2fs and xfs might bloody well return NULL without hashing - happens
> on negative lookups with 'casefolding' crap.
>
> kernfs - treatment of inactive nodes.
>
> afs_dynroot_lookup() treatment of @cell... names.
>
> afs_lookup() treatment of @sys... names.
>
> There might very well be more - both merged into mainline and in
> development trees of various filesystems (including devel branches
> of in-tree ones - I'm not talking about out-of-tree projects).
>
> Note, BTW, that with the current rules it's perfectly possible to
> have this kind of fun:
> a name that resolves to different files for different processes
> unlink(2) is allowed and results depend upon the calling process
>
> All it takes is ->lookup() deliberately *NOT* hashing the sucker and
> ->unlink() acting according to dentry it has gotten from the caller.
> unlink(2) from different callers are serialized and none of that
> stuff is ever going to be hashed. d_alloc_parallel() might pick an
> in-lookup dentry from another caller of e.g. stat(2), but it will
> wait for in-lookup state ending, notice that the sucker is not hashed,
> drop it and retry. Suboptimal, but it works.
>
> Nothing in the mainline currently does that. Nothing that I know of,
> that is. Sure, it could be made work with the changes you seem to
> imply (if I'm not misreading you) - all it takes is lookup
> calling d_lookup_done() on its argument before returning NULL.
> But that's subtle, non-obvious and not documented anywhere...
>
> Another interesting question is the rules for unhashing dentries.
> What is needed for somebody to do temporary unhash, followed by
> rehashing?
>

\
 
 \ /
  Last update: 2022-09-05 01:35    [W:0.052 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site