Re: [PATCH RFC v2 33/42] fs: add file_check_backing()

[Christian Brauner]

On Sun, Nov 15, 2026 at 12:19:57AM +0100, Amir Goldstein wrote:
> On Sat, Nov 14, 2026 at 9:06 PM Chris Down <chris@xxxxxxxxxxxxxx> wrote:
> >
> > Hi Christian,
> >
> > Christian Brauner writes:
> > >+      /* Look through stacking filesystems at the inode with the data. */
> > >+      if (d_real_inode(file->f_path.dentry)->i_sb->s_iflags & SB_I_PSEUDO)
> > >+              return -EINVAL;
> >
> > This looks good in general, but what the bots said about O_PATH files
> > here is real. With FMODE_PATH this is reached for a file that was never
> > opened, so on overlayfs nothing has been through ovl_open() to look up
> > the lowerdata of a metacopy file yet. ovl_d_real() then does the lookup
> > itself, and when that fails it hits the WARN(1) at its end and returns
> > the overlayfs dentry, so the check passes as well.
> >
> > Only fuse passes FMODE_PATH, so it takes CAP_SYS_ADMIN to get there, but
> > it's easy to trigger with that. From a quick test with a metacopy file
> > whose redirect into a data-only layer points at nothing, registering an
> > O_PATH fd of it with FUSE_DEV_IOC_BACKING_OPEN gives
> >
> >      ovl_d_real(/f, 0): real dentry not found
> >      WARNING: fs/overlayfs/super.c:79 at ovl_d_real+0xc9/0x210
> >      [...]
> >       file_check_backing+0x308/0x5e0
> >       fuse_backing_new+0x219/0x4a0
> >       fuse_backing_open+0xe8/0x390
> >       fuse_dev_ioctl+0x53a/0x7d0
> >
> > and the ioctl still succeeds. A normal open of that file fails with
> > ENOENT, so nothing could have used it as a backing file anyway, but with
> > panic_on_warn this is now a panic.
> >
> > Maybe ovl_d_real() should just stop warning when the lookup fails, now
> > that it has a caller that isn't trace_uprobe?
> 
> Yeh I guess that this needs to be a Fixes for lazy data lookup.

I have a fix for that.

> The correct fix would be to teach all the callers to deal with an error.

I've also implemented that. It wasn't that hard and it's also a bug. Not
a bad one but still.

> > The check would still pass
> > for an O_PATH file whose lowerdata couldn't be looked up at that point,
> > though.
> 
> One observation relevant to this patch set is that a datadir layer has no
> business being a pseudo fs and that can and should be blocked explicitly
> at overlayfs mount time.

I agree.

> The other observation is that fuse_passthrough_open() should probably
> check the backing_file that was opened for io in addition to checking
> in fuse_backing_open(), which could have different FMODE and specifically
> could be FMODE_PATH.

Sounds good.