Re: [PATCH] ovl: add ioctls to retrieve layer file descriptors
Amir Goldstein <[email protected]> Wed, 8 Jul 2026 15:23:46 +0200
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-api,org.kernel.vger.linux-fsdevel |
|---|---|
| Message-ID | <CAOQ4uxiiVsp0BsdqfH3rCrpP6fBi-vTyfXd-TcVmFcS34MxzUQ@mail.gmail.com> |
On Wed, Jul 8, 2026 at 2:31=E2=80=AFPM Giuseppe Scrivano <[email protected]= om> wrote: > > Miklos Szeredi <[email protected]> writes: > > > On Wed, 8 Jul 2026 at 12:00, Giuseppe Scrivano <[email protected]> wr= ote: > >> > >> Add two ioctls to overlay filesystem to allow userspace to retrieve > >> information about the overlay layers: > >> > >> OVL_IOC_OPEN_LAYER: return an O_PATH fd to the root of a layer. > >> arg =3D=3D 0 returns the upper layer (-ENOENT = if > >> no upper is configured), arg >=3D 1 returns > >> lower layers (-ENOENT if index is out of > >> range). > > > > We could do this with a plain open() call. Something like the magic > > symlinks we have under /proc/PID/fd/. Question is where could these > > live... > > is there any existing user of such a mechanism? I don't see any mount > specific info under /proc or /sys. > > > > >> OVL_IOC_GET_LAYERS_INFO: copy a struct ovl_layers_info to userspace > >> with numlower, numlowerdata, and has_upper. > > > > Isn't this info obtainable via statmount(2) already? If not, it > > should be there, instead of a specialized ioctl. > > no that is not exposed by statmount and I don't see any way to export > file system specific data through it. Do you've anything in mind? > > >> --- a/fs/overlayfs/ovl_entry.h > >> +++ b/fs/overlayfs/ovl_entry.h > >> @@ -35,6 +35,8 @@ struct ovl_layer { > >> struct vfsmount *mnt; > >> /* Trap in ovl inode cache */ > >> struct inode *trap; > >> + /* Keeps the original fsmount file alive for OVL_IOC_OPEN_LAYE= R */ > >> + struct file *origin; > > > > Don't need to keep the file open: the only info missing is the > > original vfsmount, everything else is already there to reconstruct the > > file. > > I didn't manage to get that to work. As soon as the userspace process > closes the mount fd that was passed to fsconfig, the anonymous mount > namespace is destroyed and dissolve_on_fput sets mnt->mnt_ns to NULL. > > So whenever I try to use this mount again from userspace, it is not > usable because the mount namespace is empty, causing check_mnt() to > fail. > > Do you have any suggestions on how to solve this problem? The suggestion was to store origin->f_path->mnt instead of storing origin f= ile, because you only end up using the origin vfsmount. Thanks, Amir.