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 39333C677C4 for ; Tue, 10 Jun 2025 22:23:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 303E06B007B; Tue, 10 Jun 2025 18:23:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B41E6B0088; Tue, 10 Jun 2025 18:23:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A3166B0089; Tue, 10 Jun 2025 18:23:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EC6766B007B for ; Tue, 10 Jun 2025 18:23:00 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8877916110D for ; Tue, 10 Jun 2025 22:23:00 +0000 (UTC) X-FDA: 83540917320.21.A8A573F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 2817440008 for ; Tue, 10 Jun 2025 22:22:57 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aVbtlGxF; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749594178; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hLuQnm8GtR1mcurBIw5pIZijzYYYehwuFe+H/mrbon4=; b=NjXPFfwQocuePaQZXsu2aKGBN3R4qQ+fSki7EuWL+Hk6h0eVmh2Ou+c8GZ2Qdav0nl5Jna dIITh1ANHbfbeO7qQr36gQnj2jk8eLsgofKRynkxjxZm1vVEtdlDsMSyR97T0N6/ZG21Xj 5+l5h3jUKBZQo5FP0iWcnvdD7bd7WbQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749594178; a=rsa-sha256; cv=none; b=zD45nXXFX3+7j/RmCstjQ4We8EVo48m/kG8DLmJ/gthVUN0cxQeMLcWaYRUwJAbI3rkPX2 HLWbjqAV/zM+iPedp9c1dZ8rnHosd8bxn7Xb5FrQTUgDIMwGYInMLjJpHXQ7IZxaEgWCqU LJ+jYkwbG3C4xlqDYaKGuA80+rF2NLs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aVbtlGxF; spf=pass (imf27.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749594177; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=hLuQnm8GtR1mcurBIw5pIZijzYYYehwuFe+H/mrbon4=; b=aVbtlGxF6C+fKQnp3jGMDyxlIzZIPQG7LXw500xmSegPXF6OP7GibwgoYxhU5/gOAPvMc9 fTrJmExcFVRyxxbygGG9vanB/od/bT4ZL9pMNYoywIgLR8Ph2UarO+vAH71ptvVW3FQUHD lHxujTY2ns8jPt4nSmxtKTQTg+yv1fc= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-389-UmgwY1XVNS2atK4IlpdMNg-1; Tue, 10 Jun 2025 18:22:47 -0400 X-MC-Unique: UmgwY1XVNS2atK4IlpdMNg-1 X-Mimecast-MFC-AGG-ID: UmgwY1XVNS2atK4IlpdMNg_1749594167 Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-605f8bca0e3so4487375eaf.3 for ; Tue, 10 Jun 2025 15:22:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749594162; x=1750198962; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hLuQnm8GtR1mcurBIw5pIZijzYYYehwuFe+H/mrbon4=; b=XnkPm5t4cTQ2Bj2nebKsqmT8iWtEDP+/JyRtxrYFHuI6GmuHrbRhezkYVLxF5mS3nq RDjW8HI2bhhefiY4/UWlFhHK5j85B0ImiKU+yNiR51b9NOSjPRMyz9IZs4goUpT1iAMh UJ7OlPA9ME8wLmb7FMr90IGl0hKCq1mnl0wLro1hlv13PW1jvEoBwSX/niB6ABCkOumY ZYOiMjNDVoV2mX2Oq2eRcPzBIQGklfpOKWUOv6MvI+pK6UzXw2Ps3MMt6NrGQdMS98/7 2jRvCNUmLGP7nNe9AfeC/YN7HwRNbQyZoNfNCdVmt1s++/ewADN3yo8OGcBYtAPr4D/R m/kw== X-Forwarded-Encrypted: i=1; AJvYcCW69kLNN1aTvZDcU3y0HOiUsd0AL8rQl1EGxSqV9QR2M7IFeg4brEeD+Y1EZHPpA3R5yD2JyNTBcg==@kvack.org X-Gm-Message-State: AOJu0Yzm4OjKyn5BLamv1aoTkK4sdeSnHrhz2KWsw6FcNanZtfYXjDyu 93vrj74igb4J39rTQFX5Sc9JksxAesrQaCZCYSdmUIcCjDZl6EdIwf/BriAfdEYndUZ2YpR9y+m MojtitBtRtkYGYXYWXKR/dv/Gyid4SzcAK79Pc9KH0NJ+yJKkBIKxb+anK7Iy X-Gm-Gg: ASbGncvCTEJyTBRrcryKYlOnFafqFrCfhXFOQ2PIqBrQ152xDfon26j0vn1b82E03XC 6amRm5onnLS8tNDLl3vEjBk8D38G1CRQkCwDJTLiOcgSzZxI2ilLtWDTnCI4Fv19d/kzEXm6jJv 0zgPwKFFkNspkZJ3Uv8PD7ptpKf1v76MCRdoap/uuwMEX//P5jBykhksgfPLhsRj8ec0/S4y1uy K8arrK2CX9D/Bh9hL+CRR1fOTdagfpLPyhgrMmdbjfL3kBTC37NzkDMajt8GafL+wtbQcCw2oCO K3r8/k9cfNH62A== X-Received: by 2002:a4a:e842:0:b0:60b:e146:5b9b with SMTP id 006d021491bc7-610ef662d2fmr551328eaf.1.1749594162114; Tue, 10 Jun 2025 15:22:42 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEZPFHzLV7Sg4ZkCQBoFbsxw1VThpMG4z5lPpBVju0VP9CmUB6NZzQ74WH9fhjymqKd3HA8wA== X-Received: by 2002:a05:622a:a18:b0:494:b924:1374 with SMTP id d75a77b69052e-4a713c4544cmr20646161cf.43.1749594147540; Tue, 10 Jun 2025 15:22:27 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4a611150cb0sm78624171cf.11.2025.06.10.15.22.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Jun 2025 15:22:26 -0700 (PDT) Date: Tue, 10 Jun 2025 18:22:22 -0400 From: Peter Xu To: Nikita Kalyazin Cc: akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, muchun.song@linux.dev, hughd@google.com, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, jack@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, jannh@google.com, ryan.roberts@arm.com, david@redhat.com, jthoughton@google.com, graf@amazon.de, jgowans@amazon.com, roypat@amazon.co.uk, derekmn@amazon.com, nsaenz@amazon.es, xmarcalx@amazon.com Subject: Re: [PATCH v3 1/6] mm: userfaultfd: generic continue for non hugetlbfs Message-ID: References: <20250404154352.23078-1-kalyazin@amazon.com> <20250404154352.23078-2-kalyazin@amazon.com> MIME-Version: 1.0 In-Reply-To: <20250404154352.23078-2-kalyazin@amazon.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 8UlJbqyX6eO7EPVJOMRTJKKqBO3o2wCo51f17M9SmuI_1749594167 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Queue-Id: 2817440008 X-Stat-Signature: 85urqz4gxth4aniwkcuzpzaw9kkfzusq X-Rspamd-Server: rspam04 X-HE-Tag: 1749594177-692837 X-HE-Meta: U2FsdGVkX1+/tXx1fxGxoxwPsJRgOG7eFxvSuJSRv0u5K1aMTbYi6MT6a/RcDd3Na358Of18QKmQjABKizsQUmjpSDIbByAp/1jxuHEeDgs/59QE4csIc65V9ds/XlSTwy0acr18N2/YG3eC5EUerbSySJunxJ+RqVv4jK+dxD5xh0rw7E9NX+rz0XwUYfl6QSR2gGUhC5qzVYabSLVE+M5XcygusYFvuIo3Zq6++1z2H5xfkyz0ulg/hSNjEFMmz4K0yuQTUI9LJ4oqFmPNp/jY0R+TC2ER73RgZaVEvPhotUOON64k0hG8wevlM4fU0o+wiToXXa9JUkLHC9NZkKkBcGBgeYVfdiNfkyZs3VxzCZ+gi+xsB+lZirMiDovY1DioSXr2893+au93BAmtzhoR/ScvAA0KDz/TjnHUeCvJoBVwMPhjPS+CEY0s5kNxiSk4PHgMPpo5VZxHM5DB3XhOI7o6ypdDG/2gf8IRTZ+v4WBYbEJbFWMqz1YHAFpRNnw+kmjGjW2mWYhupZ+iEfPZJUjmy/+rSXSSO0WbyNJwOPl2x+Dugt+1XdeOjHewBshAt1Ex3x3xJSC9YMV9Dd0ATMGYXlE7KhkTzvinGEEvnZgL0RYbpeWcYOQ68OqgiUAMa+G5q5yvh5PJzuIh3guqYPFwKtv6BS11vEsSm4hEdlbcpyH1THx5jikNfxLHSEXRJkgxjsE0j39GMeu8lhPJA1uRNvia8zuMLWrFoa24xZpef4lcW1CwlsvfhgZLFNAHCd4KuBX0ofp/gtkJZxa3C8mywMjBkwprcpLjveZzXKOz/fRYvPVSliWqvQEmZdyblQv7036xIwaW+cfBmDuyy1npD7/qqKb6KalEiB+iCe3IBApCeeltaijaqiRNBH28RCSK/FY/1Znwb7ISufaA+yG3xMx1T93rPBerUIZ/t5sHmGk4jiUyxAVZMy5ZSJR2ZBoNyDQzKKvYc4s 2DMWcWif khnPEI+1jS3FQoTDIQWEBICxR4Z9nS4GjnHsjSVElb3wglBCI3PDuE/iZ36ViZVrTpMBl7EyoKN/ARQBBCuCg5AWA83C9bp6QRxetG6nHm0tqMNvON6phrNApbYr4G4yXgE0pnurw2mrJenry8YTt6NHdnWKLAti2jXVQeX0Tlx1sT6OmbiFlNA58ny5fWg9lsVNj8Z4AJu8vQmdBme1yOmX4bGqHjE7ZOhsXhGeunJxlXOh4B6LMeAi+XGqXz9xcuFSHMnqnXdP+eJa1SlH7uiKpP/81NV5Mc9CaU2qpEOVnpwKN9qmsLBNq7SorTDEwFJJb9XNUKr28tySzpB5WP9UI9VXjNMlUuqt6Ms3yJziqRM1dt/S8XjYL/TUkzihHlh9jmEPtMUX89m0= 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 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. > > 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. 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. Thanks, -- Peter Xu