Re: [PATCH 01/14] VFS: Add additional RESOLVE_* flags [ver #18]

On Thu, Mar 12, 2020 at 06:11:09PM +0100, Stefan Metzmacher wrote:

Am 12.03.20 um 17:24 schrieb Linus Torvalds:

quoted

On Thu, Mar 12, 2020 at 2:08 AM Stefan Metzmacher [off-list ref] wrote:

quoted

The whole discussion was triggered by the introduction of a completely
new fsinfo() call:

Would you propose to have 'at_flags' and 'resolve_flags' passed in here?

Yes, I think that would be the way to go.

Ok, that's also fine for me:-)

quoted

quoted

quoted

If we need linkat2() and friends, so be it. Do we?

Yes, I'm going to propose something like this, as it would make the life
much easier for Samba to have the new features available on all path
based syscalls.

Will samba actually use them? I think we've had extensions before that
weren't worth the non-portability pain?

Yes, we're currently moving to the portable *at() calls as a start.
And we already make use of Linux only feature for performance reasons
in other places. Having the new resolve flags will make it possible to
move some of the performance intensive work into non-linux specific
modules as fallback.

I hope that we'll use most of this through io_uring in the end,
that's the reason Jens added the IORING_REGISTER_PERSONALITY feature
used for IORING_OP_OPENAT2.

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?

Fixing the flags argument on fchmodat() to actually *implement*
AT_SYMLINK_NOFOLLOW would be a good start :-).

As for the syscalls that don't have
flags I'm thinking of the things like:

getxattr/setxattr/removexattr just off the top of my head.

Jeremy.