Re: [RFC PATCH] fs: introduce mkdirat2 syscall for atomic mkdir

On Sat, Feb 27, 2021 at 09:21:09PM -0500, Drew DeVault wrote:

On Sat Feb 27, 2021 at 9:13 PM EST, Al Viro wrote:

quoted

No to the ABI part; "on error it returns -E..., on success - 0 or a
non-negative number representing a file descriptor (zero also
possible, but unlikely)" is bloody awful as calling conventions go,
especially since the case when 0 happens to be a descriptor is not
going to get a lot of testing on the userland side.

Hm, I was just trying to mimic the behavior of open(2). Do you have a
better suggestion?

open() *always* returns descriptor or an error, for one thing.
And quite a few of open() flags are completely wrong for mkdir,
starting with symlink following and truncation.

What's more, your implementation is both racy and deadlock-prone -
it repeats the entire pathwalk with no warranty that it'll
arrive to the object you've created *AND* if you have
something like /foo/bar/baz/../../splat and dentry of bar
gets evicted on memory pressure, that pathwalk will end up
trying to look bar up.  In the already locked /foo, aka
/foo/bar/baz/../..

TBH, I don't understand what are you trying to achieve -
what will that mkdir+open combination buy you, especially
since that atomicity goes straight out of window if you try
to use that on e.g. NFS.  How is the userland supposed to make
use of that thing?