On Fri, Apr 01, 2022 at 04:17:13PM -0400, Vivek Goyal wrote: > On Thu, Mar 31, 2022 at 01:23:17PM +0200, Christian Brauner wrote: > > Now that overlay is able to take a layers idmapping into account allow > > overlay mounts to be created on top of idmapped mounts. > > > > Cc: <linux-unionfs@xxxxxxxxxxxxxxx> > > Tested-by: Giuseppe Scrivano <gscrivan@xxxxxxxxxx> > > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > > Signed-off-by: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx> > > --- > > /* v2 */ > > - Turn on support for idmapped mounts in ovl_upper_idmap() helper here > > after we've introduced it earlier in the series and made it return the > > initial idmapping. > > > > /* v3 */ > > unchanged > > --- > > fs/overlayfs/ovl_entry.h | 2 +- > > fs/overlayfs/super.c | 4 ---- > > 2 files changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/fs/overlayfs/ovl_entry.h b/fs/overlayfs/ovl_entry.h > > index 79b612cfbe52..898b002a5c6f 100644 > > --- a/fs/overlayfs/ovl_entry.h > > +++ b/fs/overlayfs/ovl_entry.h > > @@ -92,7 +92,7 @@ static inline struct vfsmount *ovl_upper_mnt(struct ovl_fs *ofs) > > > > static inline struct user_namespace *ovl_upper_idmap(struct ovl_fs *ofs) > > Same minor nit here. Will ovl_upper_mnt_userns() be better for > readability. If it is too long, may be ovl_upper_mnt_uns(). > > I have this general comment here and other places > where "idmap" has been used. "idmap" is just one property vfs > derives from user namespace associated with mnt. I don't have strong feelings here so I don't mind changing the naming. But I honestly don't know if that's wort it since the it isn't passed as an argument. But sure.
