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 C242BC433EF for ; Tue, 15 Feb 2022 22:12:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 300176B0078; Tue, 15 Feb 2022 17:12:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AE726B007D; Tue, 15 Feb 2022 17:12:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 150126B007E; Tue, 15 Feb 2022 17:12:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 050346B0078 for ; Tue, 15 Feb 2022 17:12:42 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B7C93918B6 for ; Tue, 15 Feb 2022 22:12:41 +0000 (UTC) X-FDA: 79146414522.13.0A5FFDF Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf02.hostedemail.com (Postfix) with ESMTP id 1C42D80015 for ; Tue, 15 Feb 2022 22:12:40 +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 ams.source.kernel.org (Postfix) with ESMTPS id 4C321B81D03; Tue, 15 Feb 2022 22:12:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1B71C340EB; Tue, 15 Feb 2022 22:12:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1644963158; bh=BPqqLIY3ImvN6qeE7/pDaAPIFxvHggrWbmxk+038ayU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aS08xiLS+FrfVdHvVqNYRDX80mKKpb7SU6cVoK3/6CDQovYEqaCG3fJAuNwKp9HAm DJArx1+kQyeRUkvESL8jBIeuwk2s+Hm8c19xUGa50rwZ9NMpUk1X+5qIHP/7HTGYwF 7dmdZBCHE8ZJINEJ2DSn4gBQFoSawWk5O1c1lYdA= Date: Tue, 15 Feb 2022 14:12:36 -0800 From: Andrew Morton To: cgel.zte@gmail.com Cc: hughd@google.com, mike.kravetz@oracle.com, kirill@shutemov.name, songliubraving@fb.com, 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: <20220215141236.de1a3eca3a8a52d04507c50f@linux-foundation.org> In-Reply-To: <20220215073743.1769979-1-cgel.zte@gmail.com> References: <20220215073743.1769979-1-cgel.zte@gmail.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: rspam01 X-Rspamd-Queue-Id: 1C42D80015 X-Stat-Signature: 6db38nk8t9usep5nyfidt97yy167ci48 X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=aS08xiLS; dmarc=none; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1644963160-594186 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 15 Feb 2022 07:37:43 +0000 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. What are the real-world runtime effects of this? Do we think that this fix (or one similar to it) should be backported into -stable kernels? If "yes" then Mike's 5d752600a8c373 ("mm: restructure memfd code") will get in the way because it moved lots of code around. But then, that's four years old and perhaps that's far enough back in time.