Re: [PATCH v1] hugetlbfs: fix hugetlbfs_statfs() locking

[Mina Almasry <almasrymina@google.com>]

On Fri, Apr 29, 2022 at 1:59 PM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> On 4/29/22 13:33, Andrew Morton wrote:
> > On Fri, 29 Apr 2022 13:22:06 -0700 Mina Almasry <almasrymina@google.com> wrote:
> >
> >> After commit db71ef79b59b ("hugetlb: make free_huge_page irq safe"),
> >> the subpool lock should be locked with spin_lock_irq() and all call
> >> sites was modified as such, except for the ones in hugetlbfs_statfs().
> >>
> >> ...
> >>
> >> --- a/fs/hugetlbfs/inode.c
> >> +++ b/fs/hugetlbfs/inode.c
> >> @@ -1048,12 +1048,12 @@ static int hugetlbfs_statfs(struct dentry *dentry, struct kstatfs *buf)
> >>              if (sbinfo->spool) {
> >>                      long free_pages;
> >>
> >> -                    spin_lock(&sbinfo->spool->lock);
> >> +                    spin_lock_irq(&sbinfo->spool->lock);
> >>                      buf->f_blocks = sbinfo->spool->max_hpages;
> >>                      free_pages = sbinfo->spool->max_hpages
> >>                              - sbinfo->spool->used_hpages;
> >>                      buf->f_bavail = buf->f_bfree = free_pages;
> >> -                    spin_unlock(&sbinfo->spool->lock);
> >> +                    spin_unlock_irq(&sbinfo->spool->lock);
> >>                      buf->f_files = sbinfo->max_inodes;
> >>                      buf->f_ffree = sbinfo->free_inodes;
> >>              }
> >
> > Looks good.
>
> Agree, thanks Mina!
> Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
>
> >
> > This seems to be theoretically deadlockable and less theoretically
> > lockdep splattable, so I'm inclined to cc:stable on this.
> >
> > I wonder why we didn't do that with db71ef79b59bb2e78dc4.
> >
>
> I do not think it was considered because the "less theoretically lockdep splattable" was so rare.
>
> IIRC, the issue of possibly freeing hugetlb pages in IRQ context existed
> from almost the beginning of hugetlb.  It was first discovered and 'addressed'
> with c77c0a8ac4c5.  That was not cc:stable.  Then it was discovered that c77c0a8ac4c5 was not complete, so db71ef79b59b effectively replaced c77c0a8ac4c5.  That also was not cc:stable.  I guess we could cc:stable this.
>
> Mina, did you find this with lockdep or just code inspection?

Greg Thelen found this by code inspection. He was reviewing a related
fix and noticed this particular instance of locking wasn't _irq(), and
based on previous changes it ought to be. Lockdep did not complain
about this.

> --
> Mike Kravetz