From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7CE342EAD1B for ; Mon, 13 Apr 2026 05:36:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776058594; cv=none; b=GhHO/1KoGDaTQJrBsRuSDYpXCT2Zg16nuOD6YUoyzo/QTj6uSEKD+HHQYXlam4na5WY5B6kNfmLb6UUyiwNtxoe9ss/AudwB+xe2JvBxsAU953vXowZQcVz+Ma9b8jzAy7iNs8oemGmxR4oquNQbZVJme/Nnk0XD8PnH9PzmmvQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776058594; c=relaxed/simple; bh=rFIWaQVIzDr7LJ2pLxgr0TzD6LrP2YpDnjbHqEmKV08=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gA5c0yhzVVTUeXUk6C323oWo9bAuPCQjOv9WnW11jRKRjH7IVqBiX8CdISfKQz8DXnyguj07XwB6IahIZC5EDqqYmDOyaNcJfk7j2lJpCrgAmoKDXfD6JsrbdacCuqbrGZP6Gm8U/7YPD3htUWuxbKG5O5CeUoHJTsB+BuZExHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=h1AsM6NQ; arc=none smtp.client-ip=209.85.222.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="h1AsM6NQ" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-8dfb9139008so95106685a.1 for ; Sun, 12 Apr 2026 22:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1776058592; x=1776663392; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/X2QfEAZrHNubsDZK1Rva+fNiB1w8v4TMc0y0Ptc/zQ=; b=h1AsM6NQiNmlG6J8HLnQKdP741Abn1BRxDHZlWhZQRBQpgctOF8jORxQXgQnCghtvr Zx6gJ83LDQGQ9Abu1o46TBlMnf54gD8xs7/8wg3H8PwEuHNnvmbVt0AaGEmU/KdlrALk pLiRgs/kAY7rIt2SOfaIzio2+bTK+JgnGCeY8zg+9I+BYOg0urNUT2I9eSt5NtUVMNfS EJ9BWKnNK7g9WlNP0ZY+EW44VwBuFQZ7cYvgttyDPCNNwhFZmkyl2AqIxMk2+GV7AxHM /jyP1k7QDJju0ngYZ1f+CTXY4GXAEwlpe4gs7bmUTzq+bkR/N/BIf8RNyw6GuTYhugUu aSUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776058592; x=1776663392; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/X2QfEAZrHNubsDZK1Rva+fNiB1w8v4TMc0y0Ptc/zQ=; b=UgEwnjUZJuPAVwUlWFKAatGIyIVNZtuk0fTgkiUVgkBuPBq8PCu3MxGSbX70Rfg19f ZaEfBqIw1nYeqEEVCK+Ut1qFhidG+5NPYNQFlCHYcV6zQZSbNcjYFzr4B4bk/VTzmvNw m6DztDWbwS787ih9YGhZC4tWCNJ1hbuYR5W/iQD2mt65rt7hyb8A8tAiWomrbL+MFgMP QGslT2i4wUS/KAWFUo8p/PG8zVClIa1gR4V8keBC8QXrTX4A+YTgxkIuwExfX4O0ibYo JoNe1dbOrpXHEZvkeO/g76W+vLIosyc/vS74u0wLR4krdYionsINlpDAOGf6MZSwOh0n I1KA== X-Forwarded-Encrypted: i=1; AJvYcCX0iUrWOftzTn+/uEtwhAiqA7kYqrxIEZXBnA24dZHkPf/wRwPxCrdNHivlnSOnSTKAVl2jcTmwjC7GMSg=@vger.kernel.org X-Gm-Message-State: AOJu0YwFsUdS0mLdyg/h1HENRPpvSan5ULuhJPu5np2vB0ox630jcB0U Xj4Z1ZtjLEzzOoWr7l7t5PDq5KKRqCubxgqf2tgfHFDWWc+MJsaWlFXFdw1YixQX+yZWAgVU4Xl 6U/i7 X-Gm-Gg: AeBDievsS0OzgBq50WcVzGpBKfGbyQKyPUDfIqhhmhBDSy/8eBdXkO88pdheMP8mLlW UvWZoc2f3eb+kp/PSeWlL1+42st1yZNgUwo8LyBPMbrrSJfceXEaEHu9juG9FQxXSoEsG+ocYR1 3bxS9HRJr6Z+HOOtFPrA5YUWFWlWBg8vHWHzTWRpxLelD2ZqsHfT/fBi56NtbHW5sqN/s/smp5x 9ovDjeAr5sTAX3GBOCxg3Ls7loc6hAdAZXOtgrBDIomivnToJMldJgWcoQDuZ9uPbMsUuHRZKY2 XvCtfkvR48CqSnVc6QxrFyJwpO/2+zP13VCUtHKw9TTyWht6k+NVMJLCL0z+n0Oaj8nsLAtFr8m T8CXHkYngLGl3adTAGEcjR0DTrdtXtLMJPRvdjmhyfZL/CVU1PgADriAmkH2NRY1jiQOUzZz9ue FqzCAqAwOpP33JynlfkClN33lpVgac/P/Kz71FyP28aGJ6eFfV3pLpv3+RB1W+qhbMg6BVWF1uK afbIl7aukqO X-Received: by 2002:a05:620a:4013:b0:8d7:4f7c:873b with SMTP id af79cd13be357-8ddcdbe3c79mr1768071585a.14.1776058592318; Sun, 12 Apr 2026 22:36:32 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-71-191-243-150.washdc.fios.verizon.net. [71.191.243.150]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8aca9f7e0b0sm25350806d6.11.2026.04.12.22.36.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Apr 2026 22:36:31 -0700 (PDT) Date: Mon, 13 Apr 2026 01:36:29 -0400 From: Gregory Price To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, rppt@kernel.org, peterx@redhat.com, surenb@google.com, aarcange@redhat.com, stable@vger.kernel.org Subject: Re: [PATCH] userfaultfd: preserve write protection across UFFDIO_MOVE Message-ID: References: <20260409152822.1073083-1-gourry@gourry.net> <20260412111807.42c3edf86d19528d7cb1bb7b@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260412111807.42c3edf86d19528d7cb1bb7b@linux-foundation.org> On Sun, Apr 12, 2026 at 11:18:07AM -0700, Andrew Morton wrote: > On Thu, 9 Apr 2026 11:28:22 -0400 Gregory Price wrote: > > > move_present_ptes() unconditionally makes the destination PTE writable, > > dropping uffd-wp write-protection from the source PTE. > > > > The original intent was to follow mremap() behavior, but mremap()'s > > move_ptes() preserves the source write state unconditionally. > > > > Modify uffd to preserve the source write state and check the uffd-wp > > condition of the source before setting writable on the destination. > > Please can we have a description of the userspace-visible impact of the > bug. > Simply: UFFDIO_MOVE silently drops write protection from the source PTE when moving pages to a destination, leading to missing write-protect faults after the page has been moved. I ran into this while futzing around with some user space management of VM memory, and expecting a move to continue firing WP faults after. But Sashiko actually made a useful (though obtuse) observation which has made me realize _MOVE is actually ambiguous on what to do with source region UFFD modes. > > + if (pte_uffd_wp(orig_src_pte)) > > + orig_dst_pte = pte_mkuffd_wp(orig_dst_pte); This line assumes the destination must have intended to be WP, and the the result is essentially stale uffd wp bits in the opposite case (a user not intending to carry over WP now carries it over). tl;dr: this is more of a semantic change than I'd intended, and the existing tests did not catch it. The correct solution here is to make a UFFDIO_MOVE_MODE_WP flag to copy the UFFDIO_COPY_MODE_WP pattern. Otherwise: > (presently wondering if this is backward compatible) Yes, you're right to wonder - this does break backward compatibilty. Will come back around with UFFDIO_MOVE_MODE_WP. ~Gregory