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 B0824C433F5 for ; Thu, 17 Feb 2022 13:44:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 285196B0078; Thu, 17 Feb 2022 08:44:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2346D6B007B; Thu, 17 Feb 2022 08:44:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FCC26B007D; Thu, 17 Feb 2022 08:44:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id F41B26B0078 for ; Thu, 17 Feb 2022 08:44:17 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B9E7D94FDB for ; Thu, 17 Feb 2022 13:44:17 +0000 (UTC) X-FDA: 79152390954.26.8DDB667 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id F04D740005 for ; Thu, 17 Feb 2022 13:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xMLGTKj4HTOTXdlhSUyVvWQINdLGyf8MyKTFBShV+f4=; b=YgRZ2OECOBTphRSxVwowj4LEGo MfNJFpDMUbcRjXPoQ6THgCYUAwdvAh9DZUiABlDIfEHnReQTVnR+r2Ob8djBg17cpOK4t2ZWlRSYu BK3TnQeXuf5YnCshO2gbo7prAxxOCXXmpOw3ieSqEy6RBV+p8vUrRsuVwsVSww93FmzQ8ghuu/jIf o5Sy3KYuKPSj/hsPYoIrAXExk2wUWN46Q4Kn60c3rERbMgYXOojrHB5zO8j3zvjAcBR7alCgLwq5B SDEjyoMJnme/ujnlAWjh0sYfUSau86++w1jG+2m0umDX88QXROlGHlGyxd+qj/08qFK/7ZT0MoXfX 8n6lYpGQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKh4O-00FeQI-Td; Thu, 17 Feb 2022 13:43:40 +0000 Date: Thu, 17 Feb 2022 13:43:40 +0000 From: Matthew Wilcox To: Hugh Dickins Cc: Mike Kravetz , cgel.zte@gmail.com, kirill@shutemov.name, songliubraving@fb.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, yang.yang29@zte.com.cn, wang.yong12@zte.com.cn, Zeal Robot Subject: Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE attribute problem Message-ID: References: <20220215073743.1769979-1-cgel.zte@gmail.com> <1f486393-3829-4618-39a1-931afc580835@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: F04D740005 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YgRZ2OEC; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: hgyoxwez6q8z8p7o364n9hrnr7p4joip X-Rspamd-Server: rspam11 X-HE-Tag: 1645105435-294999 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 Wed, Feb 16, 2022 at 05:25:17PM -0800, Hugh Dickins wrote: > On Wed, 16 Feb 2022, Mike Kravetz wrote: > > On 2/14/22 23:37, cgel.zte@gmail.com wrote: > > > From: wangyong > > > > > > After enabling tmpfs filesystem to support transparent hugepage with the > > > following command: > > > echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled > > > The docker program adds F_SEAL_WRITE through the following command will > > > prompt EBUSY. > > > fcntl(5, F_ADD_SEALS, F_SEAL_WRITE)=-1. > > > > > > It is found that in memfd_wait_for_pins function, the page_count of > > > hugepage is 512 and page_mapcount is 0, which does not meet the > > > conditions: > > > page_count(page) - page_mapcount(page) != 1. > > > But the page is not busy at this time, therefore, the page_order of > > > hugepage should be taken into account in the calculation. > > > > > > Reported-by: Zeal Robot > > > Signed-off-by: wangyong > > > --- > > > mm/memfd.c | 16 +++++++++++++--- > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > > > diff --git a/mm/memfd.c b/mm/memfd.c > > > index 9f80f162791a..26d1d390a22a 100644 > > > --- a/mm/memfd.c > > > +++ b/mm/memfd.c > > > @@ -31,6 +31,7 @@ > > > static void memfd_tag_pins(struct xa_state *xas) > > > { > > > struct page *page; > > > + int count = 0; > > > unsigned int tagged = 0; > > > > > > lru_add_drain(); > > > @@ -39,8 +40,12 @@ static void memfd_tag_pins(struct xa_state *xas) > > > xas_for_each(xas, page, ULONG_MAX) { > > > if (xa_is_value(page)) > > > continue; > > > + > > > page = find_subpage(page, xas->xa_index); > > > - if (page_count(page) - page_mapcount(page) > 1) > > > + count = page_count(page); > > > + if (PageTransCompound(page)) > > > > PageTransCompound() is true for hugetlb pages as well as THP. And, hugetlb > > pages will not have a ref per subpage as THP does. So, I believe this will > > break hugetlb seal usage. > > Yes, I think so too; and that is not the only issue with the patch > (I don't think page_mapcount is enough, I had to use total_mapcount). > > It's a good find, and thank you WangYong for the report. > I found the same issue when testing my MFD_HUGEPAGE patch last year, > and devised a patch to fix it (and keep MFD_HUGETLB working) then; but > never sent that in because there wasn't time to re-present MFD_HUGEPAGE. > > I'm currently retesting my patch: just found something failing which > I thought should pass; but maybe I'm confused, or maybe the xarray is > working differently now. I'm rushing to reply now because I don't want > others to waste their own time on it. I did change how the XArray works for THP recently. Kirill's original patch stored: 512: p 513: p+1 514: p+2 ... 1023: p+511 A couple of years ago, I changed it to store: 512: p 513: p 514: p ... 1023: p And in January, Linus merged the commit which changes it to: 512-575: p 576-639: (sibling of 512) 640-703: (sibling of 512) ... 960-1023: (sibling of 512) That is, I removed a level of the tree and store sibling entries rather than duplicate entries. That wasn't for fun; I needed to do that in order to make msync() work with large folios. Commit 6b24ca4a1a8d has more detail and hopefully can inspire whatever changes you need to make to your patch.