On Fri, Mar 13, 2020 at 06:28:44PM +0000, Al Viro wrote:

On Fri, Mar 13, 2020 at 08:59:01PM +1100, Aleksa Sarai wrote:

quoted

On 2020-03-12, Stefan Metzmacher [off-list ref] wrote:

quoted

Am 12.03.20 um 17:24 schrieb Linus Torvalds:

quoted

But yes, if we have a major package like samba use it, then by all
means let's add linkat2(). How many things are we talking about? We
have a number of system calls that do *not* take flags, but do do
pathname walking. I'm thinking things like "mkdirat()"?)

I haven't looked them up in detail yet.
Jeremy can you provide a list?

Do you think we could route some of them like mkdirat() and mknodat()
via openat2() instead of creating new syscalls?

I have heard some folks asking for a way to create a directory and get a
handle to it atomically -- so arguably this is something that could be
inside openat2()'s feature set (O_MKDIR?). But I'm not sure how popular
of an idea this is.

For fuck sake, *NO*!

We don't need any more multiplexors from hell.  mkdir() and open() have
deeply different interpretation of pathnames (and anyone who asks for
e.g. traversals of dangling symlinks on mkdir() is insane).  Don't try to
mix those; even O_TMPFILE had been a mistake.

Folks, we'd paid very dearly for the atomic_open() merge.  We are _still_
paying for it - and keep finding bugs induced by the convoluted horrors
in that thing (see yesterday pull from vfs.git#fixes for the latest crop).
I hope to get into more or less sane shape (part - this cycle, with
followups in the next one), but the last thing we need is more complexity
in the area.

Can we disentangle the laudable desire to keep kernel internals
simple (which I completely agree with :-) from the desire to
keep user-space interfaces simple ?

Having some way of doing a mkdir() that returns an open fd
on the new directory *is* a very useful thing for many applications,
but I really don't care how the kernel implements it. We have so much
Linux-specific code already that one more thing won't matter :-).