linux-kernel - Re: [PATCH v1] hugetlbfs: fix hugetlbfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHS8izMnxs8Btyk2PGax88vtNqoRwi5cBb0Rmfp8RSEV-WePhA@mail.gmail.com>
Date:   Mon, 2 May 2022 16:19:37 -0700
From:   Mina Almasry <almasrymina@...gle.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Oscar Salvador <osalvador@...e.de>,
        Muchun Song <songmuchun@...edance.com>,
        Michal Hocko <mhocko@...e.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] hugetlbfs: fix hugetlbfs_statfs() locking

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