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 4F50FC677C4 for ; Wed, 11 Jun 2025 12:09:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE4A56B00A0; Wed, 11 Jun 2025 08:09:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABC486B00A1; Wed, 11 Jun 2025 08:09:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D19F6B00A2; Wed, 11 Jun 2025 08:09:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7EE0C6B00A0 for ; Wed, 11 Jun 2025 08:09:41 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3FB7C140AE1 for ; Wed, 11 Jun 2025 12:09:41 +0000 (UTC) X-FDA: 83543000562.09.F757C25 Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by imf06.hostedemail.com (Postfix) with ESMTP id F41DA180013 for ; Wed, 11 Jun 2025 12:09:38 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazoncorp2 header.b="YuNrt9K/"; spf=pass (imf06.hostedemail.com: domain of "prvs=25040907c=kalyazin@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=25040907c=kalyazin@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749643779; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4usJcNNcgjXBZCgJObiiAHubx2WJa1Zhq0ik5FOjS0s=; b=2OWnVAl2qEhThYAQlxWFmRVCkPs7YKg18BTXr+6lRU5tPNLq4PgepWXeP94auzMbWHa2xU 01mjkEXGvtrmSJvXDqRJW5si6QPU7FAbCKyjeXQRgYrt/TuJqN/B+LM/f73yrq5yK4QOCv v3s9R7QF/qSt7GiT88/atqWbezCljf0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749643779; a=rsa-sha256; cv=none; b=xZ3QSN8DtB6sZDOMkhhsdHz4yRaxrXdYx4B386/OvIqEUGAio2P+znoXuOattOAnQDBDqY 7desdrWSWQzbf36Repv6HHD9Q3ogCh16hDr952hlXFj0IJDaJTyQLcjgZ/38t5M3FB4tA1 zsTISqlfpjjQSJYZgUsLvXEsAFUzheE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazoncorp2 header.b="YuNrt9K/"; spf=pass (imf06.hostedemail.com: domain of "prvs=25040907c=kalyazin@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=25040907c=kalyazin@amazon.co.uk"; dmarc=pass (policy=quarantine) header.from=amazon.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazoncorp2; t=1749643779; x=1781179779; h=message-id:date:mime-version:reply-to:subject:to:cc: references:from:in-reply-to:content-transfer-encoding; bh=4usJcNNcgjXBZCgJObiiAHubx2WJa1Zhq0ik5FOjS0s=; b=YuNrt9K/ZApSkZ8DJvbBUtCxNiGkt52hjnwcjZGNqBoNkQiA+7DzsKoW SxjIIidKphZWrZoECNyGzK46sHnuEiaqZ6QdL+UfbT20BZRzRx7f+LYpA 8AD49Gl78p0DImSl/HbxUB0BP1Q9VjgUx6fakVHq8Fbae5Yw0S3hmmaew 3zADOal0ZTPz+Hd6MbSpY6STMPsFa20sD3icK90YE0YLWqK+BRmv8Gr4k y9AJr5c3N/wpQ+XFJSZ/dUW9DgNmWgva6+1qRMC5x2M7KbufPqlODrIou ro5beVQYTgCWpXAwaka+Xgz6r+g2wQzYXsdxd5smYuo7s03oEMV1kyiR8 A==; X-IronPort-AV: E=Sophos;i="6.16,227,1744070400"; d="scan'208";a="754132407" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2025 12:09:37 +0000 Received: from EX19MTAEUB001.ant.amazon.com [10.0.10.100:12650] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.7.229:2525] with esmtp (Farcaster) id b0e5603a-39dc-44ec-9237-eee7d8ad4ba0; Wed, 11 Jun 2025 12:09:35 +0000 (UTC) X-Farcaster-Flow-ID: b0e5603a-39dc-44ec-9237-eee7d8ad4ba0 Received: from EX19D022EUC002.ant.amazon.com (10.252.51.137) by EX19MTAEUB001.ant.amazon.com (10.252.51.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Wed, 11 Jun 2025 12:09:35 +0000 Received: from [192.168.1.170] (10.106.82.32) by EX19D022EUC002.ant.amazon.com (10.252.51.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1544.14; Wed, 11 Jun 2025 12:09:33 +0000 Message-ID: <36d96316-fd9b-4755-bb35-d1a2cea7bb7e@amazon.com> Date: Wed, 11 Jun 2025 13:09:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Subject: Re: [PATCH v3 1/6] mm: userfaultfd: generic continue for non hugetlbfs To: Peter Xu CC: , , , , , , , , , , , , , , , , , , , , , , , , References: <20250404154352.23078-1-kalyazin@amazon.com> <20250404154352.23078-2-kalyazin@amazon.com> Content-Language: en-US From: Nikita Kalyazin Autocrypt: addr=kalyazin@amazon.com; keydata= xjMEY+ZIvRYJKwYBBAHaRw8BAQdA9FwYskD/5BFmiiTgktstviS9svHeszG2JfIkUqjxf+/N JU5pa2l0YSBLYWx5YXppbiA8a2FseWF6aW5AYW1hem9uLmNvbT7CjwQTFggANxYhBGhhGDEy BjLQwD9FsK+SyiCpmmTzBQJnrNfABQkFps9DAhsDBAsJCAcFFQgJCgsFFgIDAQAACgkQr5LK IKmaZPOpfgD/exazh4C2Z8fNEz54YLJ6tuFEgQrVQPX6nQ/PfQi2+dwBAMGTpZcj9Z9NvSe1 CmmKYnYjhzGxzjBs8itSUvWIcMsFzjgEY+ZIvRIKKwYBBAGXVQEFAQEHQCqd7/nb2tb36vZt ubg1iBLCSDctMlKHsQTp7wCnEc4RAwEIB8J+BBgWCAAmFiEEaGEYMTIGMtDAP0Wwr5LKIKma ZPMFAmes18AFCQWmz0MCGwwACgkQr5LKIKmaZPNTlQEA+q+rGFn7273rOAg+rxPty0M8lJbT i2kGo8RmPPLu650A/1kWgz1AnenQUYzTAFnZrKSsXAw5WoHaDLBz9kiO5pAK In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.106.82.32] X-ClientProxiedBy: EX19D001EUA002.ant.amazon.com (10.252.50.215) To EX19D022EUC002.ant.amazon.com (10.252.51.137) X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: F41DA180013 X-Stat-Signature: pn6kqkbrus67zf7k553xay6pqkcsemkg X-HE-Tag: 1749643778-739703 X-HE-Meta: U2FsdGVkX1+1EI+lBtBaUPpXXRsLLnRaYfMT1Pq2uOwv1T52GNlPdZefz3qu25W5fN2aEYRlDncjVlNMHMYWapnXh7OzD72mEtv6UR/N2zihei9nF1Wuj7sFafS/6ofU79TWMlkMPcc1CemNwZCkXx4Rsz09rf2NqwknmENaPesWOGzfBEtRzeNzHdpXq3e4p4THxQC59bJPHfLvR9PNabT6UPn/nwMFIQ4q39BUN2AnEvfaTIGONLc/uo2gRWmIO3tiD2ejRdvVhL1GnQDWQKv2FUpzhPlZvgiAJdz9FfJAvjujLtrn+cFxWgRWkQEoag+rEygpZzOFywK1ioCXsVMC2hm8Dqn25DIIYm2Bd/9qk6rlBxd0WZnD0svdZvbA0rNTEvKBsGJ2Q6cZNFdcF8zH0lWE7dxGW2V7IrxsnX954TFZ3LDf9vbzwY7n+gVMkLo4zPFEtBdDLDrUN6paJgO8TwNGhpNczTLp1I3XXhhe6dsEKb0knDdRPs87Q+sOxTvkco9eUkdhmRl4dhD186VCUPgQc5x4GQxI3pgjDNHrr0KiFTVXickQSqlE4/SFAqIVQDcAgiZbtF4Oc/6drgdEPCfqc4euHS2b1ybEVdovEgYC4C6rtF3291fBcIG65AlHAFj3Q8RTUSfAMJrjr1rieoxDneuoOjjOBJrzdd5hsl3vzVdVEW5U8xF0ZjWVbmH3q2w6QfiWeFJ633e1hczc/vlqikrrdgnep+GWWj02rOaEMhKoD0H2Ogu3AJq4BacHcjC8nkndC/76EUlXorA5tJjtE9hXurMfc5vTdPjmR8zGhfNednCoeMOt2B7d/eKtmY4nQOP+flhnyc+gfHHnbFip1wzEGhnLIBUJ8wUnQjHwCgWTHLYaXdDh8oLHzEt988Ad+Vs602rp+IGAd6XFaLwKPc0JkufvLlTgqW9ETu5sL2FTa5PH4lhkJU5SY0A+G869fRvbMKOSqr2 8S9NNrJH dRial2RylHoYhePCtq4m84/3s5ssO7I7FjRcaXWtKMlgoKnblEfeOMq/HBXN3Nrw2RKYuLz5beg3BwD3h8pRyPOL9hAi13QqFQV6NkVWovhaAHAAxtMu1tDNMjvTHF+E4d9RsjrPHQX7mgF0BIbP8Jf8w2GXhKvUcVmk+ZXBRHvN1igEivwTS6syA1z6jGvuvvOpcZn1n1IQUyb89pI7UdZLjpbGFmSOjCn+2txmHHw7F7NwuNLmmoR/zMsk2X9zgAuHVwWTIu+8K8smuvlMoimTfhvpWsrcCjtv8I0ln+z4q0zm/k1SEuc39I/pjyUkeIUoBDeypUYgyGXfaYpdCvVBy/2hYkBZGCTAB5ZoQNirdHMrA6/TnvqqgSSHht4/FqAtwxNuH0INW+vdpPB0++y6m/7iiHsTW7pSC+2mZ23hclk3xbl+sKmQEnK0+miV9qgpp0fwV0g2e7aBRYUQx3YuHA4T3eWXnliY6zV73RJgeY0S5Nhpk8Wspbztlp2MWf3GGLSA8meDqEiCXeMiwZK0CG9O8PhgvzAdU4nCKayQX6I9SAooswdnYv4riEg/yN2QqlPK0oJA5PlEuPXKw0rfoBa+2HKTphzpi2J9zq0AJ5D0Zorls1PwcQqc5sVHa1BvSdPb/Ncncb2QZxjkEGk8Rj8fgRrP2sh3DBh8mxwLSMo3qEpjmNZCllTp7BW1R9sP3LmEDdP6NtWwHwmgqSJbAp61PvQJY8Fc/ibQzg+XFG2S6ILK2u6D+Uxs8EMg/VTONUt6sjTTXHzSmoX+NV7WfyykDzu0Oe8Yal4EKlxh0Fo92gYVFGbB/3D0hROreHpJZeyyGPuzwApT9QKW4Crfda94czljl0aImpj0Aa1h6W1HecMAskIEvSbbLV4qfXrpTbNbVyfa4Fgw= 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: List-Subscribe: List-Unsubscribe: On 10/06/2025 23:22, Peter Xu wrote: > On Fri, Apr 04, 2025 at 03:43:47PM +0000, Nikita Kalyazin wrote: >> Remove shmem-specific code from UFFDIO_CONTINUE implementation for >> non-huge pages by calling vm_ops->fault(). A new VMF flag, >> FAULT_FLAG_USERFAULT_CONTINUE, is introduced to avoid recursive call to >> handle_userfault(). > > It's not clear yet on why this is needed to be generalized out of the blue. > > Some mentioning of guest_memfd use case might help for other reviewers, or > some mention of the need to introduce userfaultfd support in kernel > modules. Hi Peter, Sounds fair, thank you. >> >> Suggested-by: James Houghton >> Signed-off-by: Nikita Kalyazin >> --- >> include/linux/mm_types.h | 4 ++++ >> mm/hugetlb.c | 2 +- >> mm/shmem.c | 9 ++++++--- >> mm/userfaultfd.c | 37 +++++++++++++++++++++++++++---------- >> 4 files changed, 38 insertions(+), 14 deletions(-) >> >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h >> index 0234f14f2aa6..2f26ee9742bf 100644 >> --- a/include/linux/mm_types.h >> +++ b/include/linux/mm_types.h >> @@ -1429,6 +1429,9 @@ enum tlb_flush_reason { >> * @FAULT_FLAG_ORIG_PTE_VALID: whether the fault has vmf->orig_pte cached. >> * We should only access orig_pte if this flag set. >> * @FAULT_FLAG_VMA_LOCK: The fault is handled under VMA lock. >> + * @FAULT_FLAG_USERFAULT_CONTINUE: The fault handler must not call userfaultfd >> + * minor handler as it is being called by the >> + * userfaultfd code itself. > > We probably shouldn't leak the "CONTINUE" concept to mm core if possible, > as it's not easy to follow when without userfault minor context. It might > be better to use generic terms like NO_USERFAULT. Yes, I agree, can name it more generically. > Said that, I wonder if we'll need to add a vm_ops anyway in the latter > patch, whether we can also avoid reusing fault() but instead resolve the > page faults using the vm_ops hook too. That might be helpful because then > we can avoid this new FAULT_FLAG_* that is totally not useful to > non-userfault users, meanwhile we also don't need to hand-cook the vm_fault > struct below just to suite the current fault() interfacing. I'm not sure I fully understand that. Calling fault() op helps us reuse the FS specifics when resolving the fault. I get that the new op can imply the userfault flag so the flag doesn't need to be exposed to mm, but doing so will bring duplication of the logic within FSes between this new op and the fault(), unless we attempt to factor common parts out. For example, for shmem_get_folio_gfp(), we would still need to find a way to suppress the call to handle_userfault() when shmem_get_folio_gfp() is called from the new op. Is that what you're proposing? > > Thanks, > > -- > Peter Xu >