Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1f486393-3829-4618-39a1-931afc580835@oracle.com>
Date:   Wed, 16 Feb 2022 17:00:46 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE
 attribute problem
Content-Language: en-US
To:     cgel.zte@gmail.com, hughd@google.com, kirill@shutemov.name,
        songliubraving@fb.com, akpm@linux-foundation.org
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        yang.yang29@zte.com.cn, wang.yong12@zte.com.cn,
        Zeal Robot <zealci@zte.com.cn>
References: <20220215073743.1769979-1-cgel.zte@gmail.com>
From:   Mike Kravetz <mike.kravetz@oracle.com>
In-Reply-To: <20220215073743.1769979-1-cgel.zte@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NkpaYnhGV2ZoY3pUS0tUTm9sK0RQUlpKR3ord3lvNi8vUVVPb0NEWWlpWDhU?=
 =?utf-8?B?MG9XdFJ3R1RPcnRvNklET0UvMnloTG5UMEVZek1pVnBPVFFBaDZOOXNseVoy?=
 =?utf-8?B?cmUrNXBhR0xZNngxSFFaY3Q2VE9UYW9idk54NDBTa2ZtMkFRRmFjUDFMMDlE?=
 =?utf-8?B?TmJkOFJLRmFqMll4N1VGWU9JYTQ5MC9Tb25FODRhL3hZakowQy93YzRtT0lW?=
 =?utf-8?B?TDRJMGN6VDBOcUhYbzVlRlFBTUQraVc3ZHlGME5YNjh4V3R6MHlHSk16aGhr?=
 =?utf-8?B?M3QrSHp6UlBCWlpMUEdSSjFkOHJMbUZFTkJRV1VENDQvcjFFaWNWeERKVi80?=
 =?utf-8?B?aG5TTWZaa09mTnlKNzhIbC9Qem1xOW9PWk5xN1NwWWJETUhrY2ZkVzYrUDJz?=
 =?utf-8?B?cTcyeUpaelB4VUZzTmVDRkJod1lXRndlb0l5T090NGZmWGordG14citKTkRi?=
 =?utf-8?B?NHdMNFFqYURQbTR0bXdkNGFjVE9meUdFQXdBOHNpMXZETnYxVVdOKzNtRkNB?=
 =?utf-8?B?UmZiYW5GSHNCcTVxcnUxWTk4K2hvbUhwL2RhUGIvdFZpRU9mclgvQWQ5ZlJx?=
 =?utf-8?B?eDNwVDdScG9FUnAxcGFLZlVFK0MxMHdpVEJjaGE2ZGpmenNGbFRTL1hhM2Mw?=
 =?utf-8?B?MmJXMkVBaElrSGltdWc3bkFXY3g1T09RUnVMLzdGZUVnbnBFRitDR01ObWdv?=
 =?utf-8?B?UE9CWG9abkhmU0xkL3hhbE9PemNHYXJVcHA3SzRXZllFZ1J3a3A4WHMyemxp?=
 =?utf-8?B?UzJsYnJHdzBwY2JZV2lGODA4VUg3Z0EwRjdRRjZOSGhXWXU3NzJBMzlXdkZw?=
 =?utf-8?B?ODV1ZlpUakJLTU0vam1jSlpxNHl0eUhzMnh2ZDZyTkZBVStvMG9sY0tOTFAx?=
 =?utf-8?B?L2hoalJSQlQ5QU9Za29pKzluazk1SHZIU1V2NUlVa0NYTTRMSnFuV1lWM0xp?=
 =?utf-8?B?STVIbCtNcjZNYU9oOUc3dXg0VXpMcmVTbjJZRndaR29nTSt0Z1EzY1hhU1RY?=
 =?utf-8?B?VTZzWTJ2cXg1QjUwMHoxS0loMVBpU2MyTy9WbTc5MURFT1ZYdGpZZGc5bStn?=
 =?utf-8?B?bGVVOHBjL1dLem8wd2hSeEhLT0xYNjZiamZtc3BBNFRiMm1WZ3lEa0dtRnli?=
 =?utf-8?B?U1cxZ3pXZjZzYUtjcFhvTlZnOTJ1d3owRzJmYUdTWW0ycHlxczVvNlFuWmpk?=
 =?utf-8?B?VndvQXQxZGt2SGxGdlY5T2xmeUdiNk50di9VbnpqcW5xSGpUM1BHYUZPMEhK?=
 =?utf-8?B?SUNWMGtCQ0JvNllvdzJvWU5URXlTNThKaElOR3ZOUjdLcklZbWsrY2RKWGY4?=
 =?utf-8?B?c2ZxdDZyazNOR1dVZkNJMjQxVWlIR0tBRlQ5eHd1OTBvdUpuY2ZvWHRET2gz?=
 =?utf-8?B?LytldC8xdGFkSlM2eEhrODJ0dGw5ekRWK2JURDMxTlFadTEvOVlCOWtDb3Jv?=
 =?utf-8?B?ak9rNFRpMlU0MGFiUWRwVUJ3OW5vcXRGNDRpVDNEQmM5eXF5VllNTk9MQzN3?=
 =?utf-8?B?RVJvK3ZuMUFiVStGTzhDMWhzSXhnN0dQTS9PWCttQ2FVaWhGSWJ6ZEhCOHl5?=
 =?utf-8?B?S25nODdiLy9uc0c2NXAxQ3pxUUsxa0NwNGFkbGxNMjl4TkpuWHF4emJSWERX?=
 =?utf-8?B?bjFvajNpd1pVZ29RcVJyL2hBNUt6Y0MyQU1KbmszUEFQUXJudDJEVWE2a3NE?=
 =?utf-8?B?d1orYXFIeUJvcnpYUkxyVFRJanlmNGwxMkhvKzZxR05NRmIwbDJwOVRBZjVZ?=
 =?utf-8?B?eVpjNlFSRFMxMWJGcmhXZVByOW1hTHkzYTMvSkZCbkF0ZXVKUjNiNHNVY2U1?=
 =?utf-8?B?MDBCd2FOMXpxa2h1RS93c2tTUk5QV1ZtNG5HdUNRNDFONEdnTHptNEpSM2pw?=
 =?utf-8?B?NTVYUThmTC9oNFprRUEySmplbVJqMDRQdEtSQ0w0ek9Tck1lcHhEVTlDMkZ0?=
 =?utf-8?B?S1ArSTROUE9jUVN4Wmo0Ynl5a2d2TWdnaC9MUUJsVjZUekZSZ2dyb2o3a2Zn?=
 =?utf-8?B?Q0NHMkJMYVZCaEY2YnUrSkdqNjA2a2J2OWpScmxOa0pyZFFHK3V2QlNZTjUr?=
 =?utf-8?B?SVRlTVJOOFJrRzU3VUxiTFhmNFR5V0ZHZU9aakdwOFJpOFdsNXV5TE84UjE4?=
 =?utf-8?B?Z1E1aHFvMmlxejZ0T3d6TXU4WEJNdy8zWGk1Y0dSY3NiNjdhRU5leVkvWUYr?=
 =?utf-8?Q?KthwPsGXoEr6lm7rPviMJMw=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 74aaa3c6-63a8-4cdf-2aea-08d9f1b0ef22
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2022 01:00:48.2229
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Zf+MnZvbiLWCi6SMscGUTxK8Ole09OZKTH7HpRRm2GTdSvKINthmvHyYeBWW9rxDpUYQ1bdYKsCn6FGkiGFvNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1934
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10260 signatures=675971
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 phishscore=0
 suspectscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202170002
X-Proofpoint-GUID: 2S4xlBg_z8n1Jk_N23LfYXxCDk5DwpC4
X-Proofpoint-ORIG-GUID: 2S4xlBg_z8n1Jk_N23LfYXxCDk5DwpC4
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/14/22 23:37, cgel.zte@gmail.com wrote:
> From: wangyong <wang.yong12@zte.com.cn>
> 
> 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 <zealci@zte.com.cn>
> Signed-off-by: wangyong <wang.yong12@zte.com.cn>
> ---
>  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.

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

> +			count -= (1 << compound_order(compound_head(page))) - 1;
> +		if (count - page_mapcount(page) > 1)
>  			xas_set_mark(xas, MEMFD_TAG_PINNED);
>  
>  		if (++tagged % XA_CHECK_SCHED)
> @@ -67,11 +72,12 @@ static int memfd_wait_for_pins(struct address_space *mapping)
>  {
>  	XA_STATE(xas, &mapping->i_pages, 0);
>  	struct page *page;
> -	int error, scan;
> +	int error, scan, count;
>  
>  	memfd_tag_pins(&xas);
>  
>  	error = 0;
> +	count = 0;
>  	for (scan = 0; scan <= LAST_SCAN; scan++) {
>  		unsigned int tagged = 0;
>  
> @@ -89,8 +95,12 @@ static int memfd_wait_for_pins(struct address_space *mapping)
>  			bool clear = true;
>  			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))
> +				count -= (1 << compound_order(compound_head(page))) - 1;
> +			if (count - page_mapcount(page) != 1) {
>  				/*
>  				 * On the last scan, we clean up all those tags
>  				 * we inserted; but make a note that we still