From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D0B7C433EF for ; Fri, 29 Apr 2022 20:33:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 057E96B0071; Fri, 29 Apr 2022 16:33:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 006A56B0072; Fri, 29 Apr 2022 16:33:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E11456B0073; Fri, 29 Apr 2022 16:33:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id D53F46B0071 for ; Fri, 29 Apr 2022 16:33:52 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id A85F280A12 for ; Fri, 29 Apr 2022 20:33:52 +0000 (UTC) X-FDA: 79411067904.07.2BEE9EA Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 07E43180016 for ; Fri, 29 Apr 2022 20:33:46 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 5E509CE34B2; Fri, 29 Apr 2022 20:33:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 673B9C385A4; Fri, 29 Apr 2022 20:33:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651264426; bh=mJwM9kYiqD3MWh4ufFdQRNVIdYK+ZNJ3as0lI4uuVH4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=xCvsVijlvrTtk1RzeXAoZaMixC4mvk/zmb8C9kir/tVaBvHCyYBuufanpBQfP22BL EHR91IYXvm7RHt/MWLaZ2WDdJpZXZngwe2r2TTfCodMIWPv0Y23I4IzhsdpbJPE8Z8 ScVJJn08m5xs/617bA3tMnCpsuQkvCDlmvf8FokM= Date: Fri, 29 Apr 2022 13:33:45 -0700 From: Andrew Morton To: Mina Almasry Cc: Mike Kravetz , Oscar Salvador , Muchun Song , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] hugetlbfs: fix hugetlbfs_statfs() locking Message-Id: <20220429133345.d79af45fb107340c31655c8e@linux-foundation.org> In-Reply-To: <20220429202207.3045-1-almasrymina@google.com> References: <20220429202207.3045-1-almasrymina@google.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 07E43180016 X-Stat-Signature: 93t6uze8s3txc1ijfq1z3duasx99rt3j X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=xCvsVijl; spf=pass (imf16.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1651264426-313023 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 29 Apr 2022 13:22:06 -0700 Mina Almasry 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. 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.