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: > > 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?
