Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220429202207.3045-1-almasrymina@google.com> <20220429133345.d79af45fb107340c31655c8e@linux-foundation.org>
 <152cb376-3793-0dd3-7d2d-d6197b8e014f@oracle.com>
In-Reply-To: <152cb376-3793-0dd3-7d2d-d6197b8e014f@oracle.com>
From:   Mina Almasry <almasrymina@google.com>
Date:   Mon, 2 May 2022 16:19:37 -0700
Message-ID: <CAHS8izMnxs8Btyk2PGax88vtNqoRwi5cBb0Rmfp8RSEV-WePhA@mail.gmail.com>
Subject: Re: [PATCH v1] hugetlbfs: fix hugetlbfs_statfs() locking
To:     Mike Kravetz <mike.kravetz@oracle.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Oscar Salvador <osalvador@suse.de>,
        Muchun Song <songmuchun@bytedance.com>,
        Michal Hocko <mhocko@suse.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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