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

[Al Viro <viro@zeniv.linux.org.uk>]

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?