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 0EE23C433F5 for ; Thu, 17 Feb 2022 01:25:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 377E66B0074; Wed, 16 Feb 2022 20:25:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 303196B0075; Wed, 16 Feb 2022 20:25:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 154896B0078; Wed, 16 Feb 2022 20:25:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id 00A976B0074 for ; Wed, 16 Feb 2022 20:25:32 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A4818918A9 for ; Thu, 17 Feb 2022 01:25:32 +0000 (UTC) X-FDA: 79150529304.14.C1F69CB Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf03.hostedemail.com (Postfix) with ESMTP id 399FA20005 for ; Thu, 17 Feb 2022 01:25:32 +0000 (UTC) Received: by mail-qv1-f50.google.com with SMTP id d3so5468375qvb.5 for ; Wed, 16 Feb 2022 17:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=JSwIX/NYsZ0hu1H4cWPLct5FZqQSU6n5RuasJx3jNYU=; b=FYI6wf5rAV7stlDCNtzPtDrK1dHkqGs7MmcJ89nBm65MP2Jvub4XNSSk5HywC2U6lI XRZQg4uxL8R9+5lROLpwIQODTFYRZO5cWvoCJdPBg5SP78CjJXMh7DIAeK9QM9HKnUmI /ceJRHrJhbUuJWWN6Hxy/P8v0QguslJtOfb1lSOrevd9jgowjV4UJ6rijrqO1Vy70H1z yW0aZrxTHZZry3QdUoyGk74AtvQEFrmGt6vLqQQiDpa17ggZbUII4iFsgEtLbA8spb14 obsc/6yIsOPF3eB+8z3us5wnWZEt0604uHto0CVsg5Yg+7O2m+bR0pr8o+R3ztndiZGm 2Jkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=JSwIX/NYsZ0hu1H4cWPLct5FZqQSU6n5RuasJx3jNYU=; b=fPma3UHjGWjxz87kkiLHcrTTQ/pKTWkGYtD7MlXvbB2bqLO3TP1hB2xrBrIIKP0nRY JC3rm5G3oK8uLdh1lKQcE4KUzpM9gA7H+7Cxpl7cuKWiKfUcZz2ZqKQx27bl2QSQBjJr lP8J6wXm3iyADdnnZtMUCwg5SPngnWlmPVQxhS0yFQnG1Qh8oLBd8SZB+bPNC+uU9v/H MPq871yl3l55fIZmW+XJO5EFVcH9N5FL14QG31Ld4qILCpn7tfvF+NuuVatImLoBwXek PmnyXl44vX8GzRdP3o1LXikIuLODwQdKc998FsBxDA4aa1EYRmXBLNXEGr3N6/v3KMac /V9w== X-Gm-Message-State: AOAM533TWlxBXxztlk1dyfcIInDFRefa99iI9qtFwAzIvU+r8zmKX3G9 RXyc8CyC32rtL5aWDw8QaW+uLA== X-Google-Smtp-Source: ABdhPJyOOCKmr8SIw+51Vzp+dRpE7VvJPT+7wvmz2zPTKISknB+5BagXhnJYCc0xuen7LBh6mp7T+g== X-Received: by 2002:a05:622a:4f:b0:2c9:a3f9:debd with SMTP id y15-20020a05622a004f00b002c9a3f9debdmr544892qtw.689.1645061131319; Wed, 16 Feb 2022 17:25:31 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id c21sm22843184qte.68.2022.02.16.17.25.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 17:25:30 -0800 (PST) Date: Wed, 16 Feb 2022 17:25:17 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Mike Kravetz cc: cgel.zte@gmail.com, hughd@google.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 In-Reply-To: <1f486393-3829-4618-39a1-931afc580835@oracle.com> 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 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 399FA20005 X-Stat-Signature: cadpf6d1paq8d7u6bdo8btf8bjnmhdij X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FYI6wf5r; spf=pass (imf03.hostedemail.com: domain of hughd@google.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1645061132-701958 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, 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. Andrew, please expect a replacement patch for this issue, but I certainly have more testing and checking to do before sending. Hugh > > I was trying to do some testing via the memfd selftests, but those have some > other issues for hugetlb that need to be fixed. :( > -- > Mike Kravetz