On Fri, 18 Oct 2024 at 22:03, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> See #getname.fixup; on top of #base.getname and IMO worth folding into it.
> I don't believe that it's going to give any measurable slowdown compared to
> mainline. Again, if the concerns about wasted cycles had been about routing
> the dfd,"" and dfd,NULL cases through the filename_lookup(), this does *NOT*
> happen with that patch. Christian, Linus?
I'm certainly ok with this, although I did react to the
- if (!name)
+ if (!name && dfd >= 0)
changes.
I see why you do them, but it makes me wonder if maybe
getname_maybe_null() should just get the dfd too.
And then in getname_maybe_null(), the
if (!name)
return NULL;
would become
if (!name)
return dfd >= 0 ? NULL : ERR_PTR(-EBADF);
because while I'm not entirely against it, I'm not convinced we really
want to support
fstatat(AT_FDCWD, NULL, &st, AT_EMPTY_PATH);
becoming the same as
fstat(".", &st);
IOW, I think the (NULL, AT_EMPTY_PATH) tuple makes sense as a way to
pass just an 'fd', but I'm _not_ convinced it makes sense as a way to
pass in AT_FDCWD.
Put another way: imagine you have a silly library implementation that does
#define fstat(fd,buf) fstatat(fd, NULL, buf, AT_EMPTY_PATH)
and I think *that* is what we want to support. But if 'fd' is not a
valid fd, you should get -EBADF, not "fstat of current working
directlry".
Hmm?
This is not a hugely important thing. If people really think that
doing "fstat()" on the current working directory is worth doing this
for, then whatever.
And yes, there's some argument for returning -EFAULT, but I do think
that "treat NULL+AT_EMPTY_PATH as the non-at version" argument is
stronger.
But the whole "some argument" does mean that I can certainly be
convinced that I'm just wrong.
Linus
