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 D8C2CC02180 for ; Wed, 15 Jan 2025 19:12:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C1286B007B; Wed, 15 Jan 2025 14:12:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 370B46B0082; Wed, 15 Jan 2025 14:12:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25F856B0085; Wed, 15 Jan 2025 14:12:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0869E6B007B for ; Wed, 15 Jan 2025 14:12:03 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 59499140149 for ; Wed, 15 Jan 2025 19:12:02 +0000 (UTC) X-FDA: 83010631284.05.6A36EE5 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 2B6FBA000F for ; Wed, 15 Jan 2025 19:11:59 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736968320; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3m9yi+15zKvdpnOspE8ce36Dfat1x89BwZlB0s7W0Jc=; b=lE1GBVwK8/9n22PcJERidFsbr6hxdxYx7ofNtIUYA3xfLBwarkPq2okeinbyEGGzpPBFb2 NTEi8d3zrs/c5gK3u6MkusbAg6sulj0aAXo5xtvrL4hs1yZ+WJQKHug7HKUWqyKnR3+6Nn DHOA2JevRS0suWqfQmW43OQhbVGWfW4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736968320; a=rsa-sha256; cv=none; b=Z+k6N8F/ps7VysRQ8LQYrygAtyatlJbFfFi8KgEnTSH9rJhDzbrufF/vfRTHRX6QhRwNTu 1gqedIElP1ZtLcA+pNAwXT4Wioqmuw/d6tVe8UsL/MEE4deLYVXgcd11ZkLtJgrOP7mL70 Yf0kEdx2FbmVkQz5DoNLRafK8JJeqCo= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 586BD12FC; Wed, 15 Jan 2025 11:12:27 -0800 (PST) Received: from [10.57.93.175] (unknown [10.57.93.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A7DD33F73F; Wed, 15 Jan 2025 11:11:56 -0800 (PST) Message-ID: <6ac6f8ed-1595-4f17-b415-3beb819746a1@arm.com> Date: Wed, 15 Jan 2025 19:11:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] mm: Clear uffd-wp PTE/PMD state on mremap() Content-Language: en-GB To: Lorenzo Stoakes , Peter Xu Cc: Andrew Morton , Muchun Song , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Shuah Khan , David Hildenbrand , =?UTF-8?Q?Miko=C5=82aj_Lenczewski?= , Mark Rutland , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, stable@vger.kernel.org References: <20250107144755.1871363-1-ryan.roberts@arm.com> <20250107144755.1871363-2-ryan.roberts@arm.com> <26ee9ae0-405f-4085-a864-48d1ee6371f1@arm.com> <9221000a-161b-46ea-a065-ee339837aacb@lucifer.local> From: Ryan Roberts In-Reply-To: <9221000a-161b-46ea-a065-ee339837aacb@lucifer.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2B6FBA000F X-Rspam-User: X-Stat-Signature: e8iahz47ttaqp9cqhxzzoz64jreag66t X-HE-Tag: 1736968319-612631 X-HE-Meta: U2FsdGVkX1/kwXvspeJpDQQrw5EY7PqzGYKuYB0vqLUbhaEC0HOH0+/ayfNzN4y9dkKRc6+bFQ0d7uUQuGN2MPwM1xMkeJH/pXAte7UMCjgdcCl/dI5Lud0yvd0Q58tcngTnzwmkH/P9AgP7AD8KjSSJeqx2uNT4+Wzsnu4ehprmcBSFofCv/jPthQrbAVwaC5VHmjnT5aedawPAyC7NqDb9L04J+mS8Qh0ur5spcMyVPJXVwSdcAK60hCeApN03T+Y8uhLr/EreE4JTSkGVHw1rCbfkkCqEBsC+lwkm0oloH6iRqPXNc0TQd5r8oEN+UFrvK9fdDQL1EO3kJSDvGp9eS9SWa95TPWAST6Y3ZTPkTmQqm5eYWgoZzrlSAHl39G0qygpTxe+3KShbNcW7VFnn+Np8HDrvJOB3IJjTdP3D7W4sfbUsFMFeznJE9plvbKT/dqY5PAxi4am240pBS5uu3wSO0zQV7lv8lRS7IrlwOjkxtTOBBNK60miku78wT5dHjCMmtXucoN+hoo9Tdo520mBZp6+rP/mzWa2SiuQy7fkjXpsTM8r5H3fxyehTDMMtnZj9SkZ5hCBMqUXs70s8/oO2jlay+Dd8H/viWAau2LviJIA+T0yD1b4Lj2TupejuyVWVjo19hntniqLtIANL4kONVX5icMO/DjkBD+FA7u4DJln2AbGLNzPU9vSq85ikgsDcUnGL0ifFrQgtHsWpHQBb//kElbEGaudM5dC4MXvIuUxJ3TuZLz67MzANOnS14ol67d+m4bZps8DWU0VPnBqxWXTfZ7z5WdyYWeKtU9ePFkVgyI61hTeNRNWyvb2y4Bs9qNgIy0kMazE0OLvOnET5F2r7NcxGvVKWNrzUNBhs98zqPJg3ub5F9pOo3Us1IhmDDCzoaQyr40CKhmKX51MHY23pkkwqphzoXOt74tnmqDlPeam9K/huRGFzUyPyTEf3nLzAorpfcfa aMN0bceu BY93IvJsm6HoUK7UoQEpTwOQ0vcYJzoJFT1AqziVaKQxkhF70lKkB3JSjc1Xsi4k3SUQxDMKc7QXR+n9qcUgj1iDxQPIdCNar6PqJ5UOtP8zyk9SKthZbki6JHEdN9Al7SiDsa6BvtPYq6BZieBHrnFG4sw== 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 15/01/2025 17:30, Lorenzo Stoakes wrote: > On Wed, Jan 15, 2025 at 12:21:15PM -0500, Peter Xu wrote: >> On Wed, Jan 15, 2025 at 04:58:06PM +0000, Ryan Roberts wrote: >>> Hi Peter, David, >> >> Hey, Ryan, >> >>> >>> On 07/01/2025 14:47, Ryan Roberts wrote: >>>> When mremap()ing a memory region previously registered with userfaultfd >>>> as write-protected but without UFFD_FEATURE_EVENT_REMAP, an >>>> inconsistency in flag clearing leads to a mismatch between the vma flags >>>> (which have uffd-wp cleared) and the pte/pmd flags (which do not have >>>> uffd-wp cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) >>>> to trigger a warning in page_table_check_pte_flags() due to setting the >>>> pte to writable while uffd-wp is still set. >>>> >>>> Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any >>>> such mremap() so that the values are consistent with the existing >>>> clearing of VM_UFFD_WP. Be careful to clear the logical flag regardless >>>> of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover >>>> PTE, huge PMD and hugetlb paths. >>> >>> I just noticed that Andrew sent this to Linus and it's now in his tree; I'm >>> suddenly very nervous that it doesn't have any acks. I don't suppose you would >>> be able to do a quick review to calm the nerves?? >> >> Heh, I fully trusted you, and I appreciated your help too. I'll need to run >> for 1-2 hours, but I'll read it this afternoon. Thanks - appreciate it! I was just conscious that in the original thread there was some disagreement between you and David about whether we should clear the PTE state or set the VMA state. I think we converged on the former (and that's what's implemented) but would be good to get an explicit ack. >> >> Side note: no review is as good as tests on reliability POV if that was the >> concern, but I'll try my best. > > Things go all inception though when part of the review _are_ the tests ;) > Though of course there are also all existing uffd tests and the bots that > add a bit of weight. > > This isn't really my area so will defer to Peter on the review side. > > I sort of favour putting hotfixes in quick, but this one has gone in > quicker than some reviewed hotfixes which we left in unstable... however > towards the end of a cycle I think Andrew is stuck between a rock and a > hard place in deciding how to handle these. > > So I'm guessing the heuristic is 'allow to simmer in unstable if time > permits in cycle', if known 'good egg' + no objection + towards end of > cycle + hotfix - send. > > I do wonder whether we should require review on hotfixes generally. But > then of course that creates rock + hard place decision for Andrew as to > whether it gets deferred to the next cycle + stable backports... I have no issue with the process in general. I agree it's better to go quickly - that's the best way to find the bugs. I'm really just highlighting that in this case, I don't feel sufficiently expert with the subject matter and would appreciate another set of eyes. Thanks, Ryan > > Maybe one to discuss at LSF? > >> >> Thanks, >> >> -- >> Peter Xu >>