From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from flow-b8-smtp.messagingengine.com (flow-b8-smtp.messagingengine.com [202.12.124.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93FAD32B107; Mon, 25 May 2026 15:28:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.143 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779722887; cv=none; b=UvANEQSjkgoUcIwWqd5m2BmH9bO6PnEOIquu6R5/QkLiQim+nyGjIo2TWeEdcvOkWXTMMr4fhmzkY0n0f4lu7V5gDo3Vt8/eCuvViFVcpV9lkZoKZgjV0p+okjRQSCef6V3mLBFaD07BN8/gWj1NT6M/evkgvbWDc/1Bh+/+Khk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779722887; c=relaxed/simple; bh=n3h/R3pvgEQddyisCmHXLVXbZv8Jbv4IT7zPxyMrvpU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=myVBFxgMyN0vI1p4mx/+Dqx0LXygMVDX5ku3Y5t7Y/l9my+WsD3D6Q1U+KU8C7gDBqWJRnOHFXP6uiAUwANSDZuA/mdwFtsl83LlHII0DcNBL1p9qloGdKLYIPU9TSrCpKB5sMUfIz0C2L4IwIhxuO6ZTTJfsmuDQGgS8iaD8Cs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name; spf=pass smtp.mailfrom=shutemov.name; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b=n1xkldKn; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=rsQkKnh6; arc=none smtp.client-ip=202.12.124.143 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shutemov.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shutemov.name header.i=@shutemov.name header.b="n1xkldKn"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="rsQkKnh6" Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailflow.stl.internal (Postfix) with ESMTP id D35F81300655; Mon, 25 May 2026 11:28:04 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Mon, 25 May 2026 11:28:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1779722884; x=1779730084; bh=p5sPpgY4pqLUq5Ua2SzOVVUIU5JsKkHb pOqh7qLA5oo=; b=n1xkldKnO+UgyyK5WP1utn1ROqplED9tbyhKIfk5Ph2y2E8i bh+ioh67uD83q2g9Pl0jSjqnCy/N9RF2z0e3nqXq33TDpPQGzDEC5vEwXt/AExxP SXsq11ed91ndigqOU6tkgcFbctlOuF8F6xMdNAdHmLB+5mHP6egItFcm16Br5QkQ iCbTx/Vd4/FsoMtzzN53FfVOQmaVfbpoL6G/o8ajKb+UmNph2uSEMgMP+uzUrMgg JlprDH2vTiBS1BWaembS30JKSNSdAynSOCn/8AHfAG0GzeFptQRJrxe9ikFzgjJJ 9pERlEtv48zTc0VJkO8A5iDmvDR+2rrudHIg/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1779722884; x= 1779730084; bh=p5sPpgY4pqLUq5Ua2SzOVVUIU5JsKkHbpOqh7qLA5oo=; b=r sQkKnh6mYVYwvJCOyp7U4+WY+3m8/Y8VVP+pkV6Qm9EH66LrCapf/FaJqVpwCIzk ykp5M0YnN9pIsjgghK/pM9X2tLXSIsh61I6bgJDHJoGPjnpX69JVAmu5PuqhgXpp EntHWm3heubDgKoiS+FJhPsNEoo0QHQ584P9iGj6fOg7hdhjz4AjNGwb7cesrNTO m1s9IhoQ0IKT1uLR/gMOQseWMUaQW7NollOEBume0zXtbUhQZGdQnohK+wNK45ap 1+6IUKtpkjCGNqtvRzKlELxD28DqjF8huP9oQVUIBqUJRkPkrFZ8rHAp8FkrtAkD RsooIMu6fosbKj9FcqX4A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGXLYgz2/5cvkQ8YOUtgjiSVz3J+9ImrgeJIW0/3ROMrwzEaSSHOx7KIOSgYiHDEY NT5qr4GwcU+hQVbqBcRP64Trk2rAAQKYWKvqyq63fviDvjzNhw7gjZOqttQ4zj3NO8xpuu xZRzrkFxrIPiCAx0dtQ++u/KifT00VuJQkwjlD8MUzsDBrqYNAZA5Xo3ZDvu6nVv/5Bx0u i7hdnuOij6YYWkpIpHhP27CBcoX+k5d1uygQStSEPTqSC6DIQ/wVTIPhLkvWWeyEDnaLmt V1IRjTA5IqqrEzomoekCXRcktA1GJtLxGZpLYagD7rk+xa4f9FwpBoi0M09uo36Gqn3LbY o4Al6LDEsOMosIdcXLmH3skHumIaUAe1qk4Xp+HHVxXcF5dNfaAfuzur7+i8tzKXo9S/xM ENwiCdGi/VJ+Z4jOaJm+5sa7uAr8Oqen811PiPux//4OZigp0jwIa0ctjJRFPPR+nW7pn3 +WJRQ6tRvXpWBDT0VS3Eo3ME1O5Zc9C0TE1Trc7gGVLKXlhU0KY36o9KvbnnXSo1Q0XQXy Zze3D17t1YtNnacPlFC+XTW/C61QYrUqltlqs/L8WrNuh/Iq20lWy1aU1x+seN8CjBwH5t 9jYuuUFEc+JPuzsjZinTuRV0xHFyCaB+0yRe2ziRc67Vh9n46NOpQ5fSq5eQ X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 25 May 2026 11:28:01 -0400 (EDT) Date: Mon, 25 May 2026 16:27:55 +0100 From: Kiryl Shutsemau To: sashiko-reviews@lists.linux.dev Cc: kvm@vger.kernel.org, akpm@linux-foundation.org, rppt@kernel.org, peterx@redhat.com, david@kernel.org, ljs@kernel.org, surenb@google.com, vbabka@kernel.org, Liam.Howlett@oracle.com, ziy@nvidia.com, corbet@lwn.net, skhan@linuxfoundation.org, seanjc@google.com, pbonzini@redhat.com, jthoughton@google.com, aarcange@redhat.com, sj@kernel.org, usama.arif@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v4 09/14] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP Message-ID: References: <20260525113737.1942478-10-kas@kernel.org> <20260525121858.57D0B1F000E9@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260525121858.57D0B1F000E9@smtp.kernel.org> On Mon, May 25, 2026 at 12:18:57PM +0000, sashiko-bot@kernel.org wrote: > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider: > > New issues: > - [High] UFFD RWP tracking is bypassed or causes an infinite loop > during GUP FOLL_FORCE accesses on PROT_NONE VMAs. Will fix in v5 by rejecting UFFDIO_REGISTER_MODE_RWP on PROT_NONE VMAs in vma_can_userfault(), so this state can't be set up to begin with. > - [High] Orphaned RWP-protected PTEs cause an unrecoverable infinite > page fault loop in hugetlb_fault(). Fork goes through copy_hugetlb_page_range() with the pte_uffd gate I'm adding for the 06/14 finding) the orphan state isn't produced. > - [High] NUMA balancing silently strips userfaultfd RWP protection from adjacent PTEs within a large folio. Confirmed. NUMA scanning already skips RWP-armed PTEs (the pte_protnone() guard in change_pte_range()), so the two never coexist on a given folio at apply time -- but numa_rebuild_large_mapping() is the one place they can meet. Will fix in v5 by gating the rebuild on pte_uffd(): + if (pte_uffd(ptent)) + continue; > - [Medium] Missing feature capability check in userfaultfd_register > allows enabling RWP without negotiating the feature. The check is there -- mm/userfaultfd.c: if (uffdio_register.mode & UFFDIO_REGISTER_MODE_RWP) { if (!pgtable_supports_uffd() || VM_UFFD_RWP == VM_NONE) goto out; if (!(ctx->features & UFFD_FEATURE_RWP)) goto out; vm_flags |= VM_UFFD_RWP; } > Pre-existing issues: > - [High] Calling present-PTE accessors on potentially non-present swap or migration entries in must_wait() handlers. Confirmed and pre-existing -- userfaultfd_must_wait() reads the PTE locklessly and applies pte_write() / pte_protnone() / pte_uffd() without checking pte_present(). The pre-patch pte_write() path has the same shape on master. Will address in a separate fix. > -- > Sashiko AI review · https://sashiko.dev/#/patchset/20260525113737.1942478-1-kas@kernel.org?part=9 -- Kiryl Shutsemau / Kirill A. Shutemov