On Thu, Mar 12, 2020 at 06:11:09PM +0100, Stefan Metzmacher wrote: > Am 12.03.20 um 17:24 schrieb Linus Torvalds: > > On Thu, Mar 12, 2020 at 2:08 AM Stefan Metzmacher <metze@xxxxxxxxx> wrote: > >> > >> 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:-) > > >>> 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. > > > 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.
