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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux