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
