Re: [PATCH] ovl: make consistent use of OVL_FS()

From: Andrea Righi
Date: Sat May 20 2023 - 09:20:00 EST


On Sat, May 20, 2023 at 03:33:32PM +0300, Amir Goldstein wrote:
> On Sat, May 20, 2023 at 3:20 PM Andrea Righi <andrea.righi@xxxxxxxxxxxxx> wrote:
...
> > @@ -97,6 +99,8 @@ static inline struct mnt_idmap *ovl_upper_mnt_idmap(struct ovl_fs *ofs)
> >
> > static inline struct ovl_fs *OVL_FS(struct super_block *sb)
> > {
> > + /* Make sure OVL_FS() is always used with an overlayfs superblock */
> > + BUG_ON(sb->s_magic != OVERLAYFS_SUPER_MAGIC);
>
> 1. Adding new BUG_ON to kernel code is not acceptable - if anything
> you can add WARN_ON_ONCE()

OK, but accessing a pointer to a struct ovl_fs that is not really a
struct ovl_fs can potentially have nasty effects, even data corruption
maybe? I'd rather crash the system now rather than experiencing random
behaviors later...

> 2. If anything, you should check s_type == s_ovl_fs_type, not s_magic

Hm.. is there a fast way to determine when sb->s_type == overlayfs?
Using get_fs_type() here seems quite expensive and I'm not even sure if
it's doable, is there a better way that I don't see?

> 3. It is very unclear to me that this check has that much value and OVL_FS()
> macro is very commonly used inside internal helpers, so please add a
> "why" to your patch - why do you think that it is desired and/or valuable
> to fortify OVL_FS() like this?

Sure, I can send a v2 explaining why I think this is needed. Basically I
was debugging a custom overlayfs patch and after a while I realized that
I was accessing the sb->s_fs_info of a real path (not an overlayfs sb),
using OVL_FS() with a proper check would have saved a me a bunch of
time.

Thanks for looking at this!
-Andrea