v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[J. R. Okajima]

Hello Al Viro,

By the commit in v7.0-rc1,
	154ef7dce6a4d 2026-01-16 name_to_handle_at(): use CLASS(filename_uflags)
name_to_handle_at(2) stopped handling AT_EMPTY_PATH, and an application
which issues
	name_to_handle_at(fd, "", handle, &mnt_id, AT_EMPTY_PATH);
started failing.

It is due to the commit dropped setting LOOKUP_EMPTY to lookup_flags in
name_to_handle_at(2).
The commit log is empty and I'd ask you "Is it intentional or an
accident?"


J. R. Okajima

Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[Al Viro]

On Fri, Feb 27, 2026 at 07:44:58PM +0900, J. R. Okajima wrote:
> Hello Al Viro,
> 
> By the commit in v7.0-rc1,
> 	154ef7dce6a4d 2026-01-16 name_to_handle_at(): use CLASS(filename_uflags)
> name_to_handle_at(2) stopped handling AT_EMPTY_PATH, and an application
> which issues
> 	name_to_handle_at(fd, "", handle, &mnt_id, AT_EMPTY_PATH);
> started failing.
> 
> It is due to the commit dropped setting LOOKUP_EMPTY to lookup_flags in
> name_to_handle_at(2).

Huh?
	CLASS(filename_uflags, filename)(name, flag);
*does* accept empty path if flag & AT_EMPTY_PATH is non-zero.

So if you are really observing such failures, something else must've gone
wrong.  Details, please.

This
struct filename *getname_uflags(const char __user *filename, int uflags)
{
        int flags = (uflags & AT_EMPTY_PATH) ? LOOKUP_EMPTY : 0;

	return getname_flags(filename, flags);
}
is where AT_EMPTY_PATH is handled; could you check the arguuments it's getting
in your reproducer and argument passed to getname_flags()?

Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[hooanon05g]

Al Viro:
> This
> struct filename *getname_uflags(const char __user *filename, int uflags)
> {
>         int flags = (uflags & AT_EMPTY_PATH) ? LOOKUP_EMPTY : 0;
>
> 	return getname_flags(filename, flags);
> }
> is where AT_EMPTY_PATH is handled; could you check the arguuments it's getting
> in your reproducer and argument passed to getname_flags()?

getname_flags() is not a problem.
For me, the problem looks that LOOKUP_EMPTY is NOT passed to
path_lookupat().


J. R. Okajima

Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[Al Viro]

On Sat, Feb 28, 2026 at 12:41:04AM +0900, hooanon05g@gmail.com wrote:
> Al Viro:
> > This
> > struct filename *getname_uflags(const char __user *filename, int uflags)
> > {
> >         int flags = (uflags & AT_EMPTY_PATH) ? LOOKUP_EMPTY : 0;
> >
> > 	return getname_flags(filename, flags);
> > }
> > is where AT_EMPTY_PATH is handled; could you check the arguuments it's getting
> > in your reproducer and argument passed to getname_flags()?
> 
> getname_flags() is not a problem.
> For me, the problem looks that LOOKUP_EMPTY is NOT passed to
> path_lookupat().

Could you please show me a single place in path_lookupat() where we would
check for for LOOKUP_EMPTY?

The last point where LOOKUP_EMPTY (or AT_EMPTY_PATH) matters is (and had
always been) getname_flags(); pathname resolution proper doesn't care.

In theory some out-of-tree filesystem might have been playing silly
buggers with LOOKUP_EMPTY in its ->d_revalidate(); there's no good
reason for doing so, though, and none of the in-tree filesystems had
ever tried to pull that off.

Could you describe the reproducer in more details?

Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[Al Viro]

On Fri, Feb 27, 2026 at 06:48:04PM +0000, Al Viro wrote:
> On Sat, Feb 28, 2026 at 12:41:04AM +0900, hooanon05g@gmail.com wrote:
> > Al Viro:
> > > This
> > > struct filename *getname_uflags(const char __user *filename, int uflags)
> > > {
> > >         int flags = (uflags & AT_EMPTY_PATH) ? LOOKUP_EMPTY : 0;
> > >
> > > 	return getname_flags(filename, flags);
> > > }
> > > is where AT_EMPTY_PATH is handled; could you check the arguuments it's getting
> > > in your reproducer and argument passed to getname_flags()?
> > 
> > getname_flags() is not a problem.
> > For me, the problem looks that LOOKUP_EMPTY is NOT passed to
> > path_lookupat().
> 
> Could you please show me a single place in path_lookupat() where we would
> check for for LOOKUP_EMPTY?
> 
> The last point where LOOKUP_EMPTY (or AT_EMPTY_PATH) matters is (and had
> always been) getname_flags(); pathname resolution proper doesn't care.
> 
> In theory some out-of-tree filesystem might have been playing silly
> buggers with LOOKUP_EMPTY in its ->d_revalidate(); there's no good
> reason for doing so, though, and none of the in-tree filesystems had
> ever tried to pull that off.

To elaborate a bit: LOOKUP_EMPTY has ever had only one purpose - to tell
getname...() that empty pathname is not to be rejected.  This is _all_
- e.g. a combination of LOOKUP_EMPTY with non-empty pathname has always
been possible.  It simply does not carry any useful information past
that check on pathname import.

Nothing in pathname resolution checks it; of the few filesystem methods
that might see something of nd->flags, only ->d{_weak}_revalidate() would
have a chance to see that one for an empty pathname (no components to
look up, obviously).  And considering how uninformative LOOKUP_EMPTY would
be for that method... not a single in-tree instance had bothered to check.

Note that combination of AT_EMPTY_PATH with a non-empty pathname
has always been legitimate, and it would better behave exactly
like the call the same non-empty pathname and AT_EMPTY_PATH
removed from the flags.  So if LOOKUP_EMPTY changes behaviour of
->d_weak_revalidate()/->d_revalidate(), it's almost certainly a bug.

Is your testcase on the mainline kernel?  If not, is there an out-of-tree
filesystem involved?  Are there any kprobes/bpf programs/etc. stuck
into the guts of fs/namei.c?  struct nameidata shouldn't be even visible
to any of those, but...

Re: v7.0-rc1, name_to_handle_at(..., AT_EMPTY_PATH)

[hooanon05g]

Al Viro:
> The last point where LOOKUP_EMPTY (or AT_EMPTY_PATH) matters is (and had
> always been) getname_flags(); pathname resolution proper doesn't care.

Filesystems recieved LOOKUP_EMPTY before v7.0-rc1 and could use it to
detect a case like this.

	fd = open("fileA");
	unlink("fileA");
	name_to_handle_at(fd, "", fh, &mnt_id, AT_EMPTY_PATH);

The flag was used to support
- unlinked but still alive inode
- without its name
and d_revalidate() should handle it still valid.

Yes, the filesystem is out-of-tree.
Now I understand that LOOKUP_EMPTY is not passed to filesystem
intentionally.


Thank you
J. R. Okajima