On Fri, Apr 29, 2022 at 1:59 PM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 4/29/22 13:33, Andrew Morton wrote: > > On Fri, 29 Apr 2022 13:22:06 -0700 Mina Almasry <almasrymina@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > > 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