Re: [PATCHSET v2 0/6] Allow allocated direct descriptors

[Stefan Metzmacher <metze@samba.org>]

Am 10.06.22 um 13:06 schrieb Hao Xu:
> Hi Stefan,
> On 6/9/22 16:57, Stefan Metzmacher wrote:
>>
>> Hi Jens,
>>
>> this looks very useful, thanks!
>>
>> I have an additional feature request to make this even more useful...
>>
>> IO_OP_ACCEPT allows a fixed descriptor for the listen socket
>> and then can generate a fixed descriptor for the accepted connection,
>> correct?
> 
> Yes.
> 
>>
>> It would be extremely useful to also allow that pattern
>> for IO_OP_OPENAT[2], which currently is not able to get
>> a fixed descriptor for the dirfd argument (this also applies to
>> IO_OP_STATX, IO_OP_UNLINK and all others taking a dirfd).
>>
>> Being able use such a sequence:
>>
>> OPENTAT2(AT_FDCWD, "directory") => 1 (fixed)
>> STATX(1 (fixed))
>> FGETXATTR(1 (fixed)
>> OPENAT2(1 (fixed), "file") => 2 (fixed)
>> STATX(2 (fixed))
>> FGETXATTR(2 (fixed))
>> CLOSE(1 (fixed)
>> DUP( 2 (fixed)) => per-process fd for ("file")
>>
>> I looked briefly how to implement that.
>> But set_nameidata() takes 'int dfd' to store the value
>> and it's used later somewhere deep down the stack.
>> And makes it too complex for me to create patches :-(
>>
> 
> Indeed.. dirfd is used in path_init() etc. For me, no idea how to tackle
> it for now.We surely can register a fixed descriptor to the process
> fdtable but that is against the purpose of fixed file..

I looked at it a bit more and the good thing is that
'struct nameidata' is private to namei.c, which simplifies
getting an overview.

path_init() is the actual only user of nd.dfd
and it's used to fill nd.path, either from get_fs_pwd()
for AT_FDCWD and f.file->f_path otherwise.

So might be able to have a function that translated
the fd to struct path early and let the callers pass 'struct path'
instead of 'int dfd'...

metze