lkml.org 
[lkml]   [2022]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v1] hugetlbfs: fix hugetlbfs_statfs() locking
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

\
 
 \ /
  Last update: 2022-05-03 01:25    [W:0.065 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site