From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 9D77E38E5F9 for ; Tue, 2 Jun 2026 04:10:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780373406; cv=none; b=Uzucm5VLZ5EHBaL0WrQQ+IY3dyFkFlCqJtkUBr+r57+kTjUKzzLQMXtHTU0HXptHP6TY+cQqEikmZFSH8E9WVVsiL94NoO5X+aWrEnkWzSArOtJv0ZQgmfoqeDdKelIAKixwd37Qe/QNgkSOci2oNqjbc4FZLr4svfJLyecB548= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780373406; c=relaxed/simple; bh=LiLxG9ENEyKR35xQBfVP3+knBMpHShuwpk+b6x6KCwI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Elee/KMWWBA34hD/Z0t7jN+BQjMSqLDvFGt7hvAVBQtlBzahCVckjiDc/gXg0aHevffzy6GqwQWTiDOeYMiiYAu0+D5ZeVqcwIKtQ0IzA8TCrED/7ElKLdYT4IWn/A7pjOOHEJuNEuNdEiurQEtr1h8j/ZQ9xf6alb7e2yFeMbQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CCnkphUC; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CCnkphUC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D34C81F00893; Tue, 2 Jun 2026 04:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780373405; bh=RprQiT8iFE4bavkRAkUlxYO6/YAO1eRv5LSSO66hPdw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=CCnkphUCLKzsOe8oZU9g4I49LlxWnjIbhTr81AptOG3GxufizbsO7Cq6XmF4R1d0Q qpnzcfP8QgQvVt0d1ubk5KMak7QcIybEWLFfDcTAQvF/4HSi+R9pkLPRcurFO+879t mpYIvub/LUwNGxuH0jIHp0p8YZIrQUxNNm8e+WNwqPOvNSEEiLoLFeErQuvHDERk+O ctfCRN6g8D9SQeLejpGTs+CoK/ZkcamMYwSyBOB0yiER21jOAUD3VoqlYKLTZOW9XS kTB/7spli2HK23TeuXHIn5MmYuwMV1fKBSXOjSehNlJUK21nM7d5UEDIGMCLPG/l9C bDx9YEaC/NYGA== Date: Tue, 2 Jun 2026 06:09:57 +0200 From: "Oscar Salvador (SUSE)" To: Lorenzo Stoakes Cc: Andrew Morton , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , SeongJae Park , Balbir Singh , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH mm-hotfixes] mm/huge_memory: use correct flags for device private PMD entry Message-ID: References: <20260601083044.57132-1-ljs@kernel.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: <20260601083044.57132-1-ljs@kernel.org> On Mon, Jun 01, 2026 at 09:30:44AM +0100, Lorenzo Stoakes wrote: > Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support > device-private entries") updated set_pmd_migration_entry() to use > pmdp_huge_get_and_clear() in the softleaf case, but made no further > adjustments to the function itself. > > Therefore this function continues to incorrectly use pmd_write(), > pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed > migration entry should be marked writable, softdirty or uffd-wp > respectively. > > Whilst all are incorrect, the most problematic of these is pmd_write(), as > this can lead to corrupted rmap state. > > On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling > pmd_write() on a softleaf will return the softdirty state encoded in the > entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled. > > This was observed when running the hmm.hmm_device_private.anon_write_child > selftest: > > 1. The test faults in a range then migrates it such that a device-private > THP range is established. > > 2. The parent then migrates it to a device-private writable PMD entry whose > folio is entirely AnonExclusive with entire_mapcount=1, softdirty set > (accidentally correct write state). > > 3. The parent forks and the PMD entries are set to device-private read only > entries, entire_mapcount=2, softdirty still set. > > 4. [BUG] The child writes to the range then migrates to RAM - intending to > install non-writable migration entries - but replacing parent and child > PMD mappings with WRITABLE entries due to misinterpreting the softdirty > bit. > > 5. In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we > set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for > both parent and child, which are therefore AnonExclusive. > > 6. [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets > entire_mapcount=2 and we end up with an AnonExclusive folio with > entire_mapcount=2! Assert fires in __folio_add_anon_rmap(): > > VM_WARN_ON_FOLIO(folio_test_large(folio) && > folio_entire_mapcount(folio) > 1 && > PageAnonExclusive(cur_page), folio) > > This patch fixes the issue by correctly referencing the softleaf entry > fields for writable, softdirty and uffd-wp in set_pmd_migration_entry(). > > It also only updates A/D flags if the entry is present as these are > otherwise not meaningful for a softleaf entry. > > This patch also flips the if (!present) { ... } else { ... } logic in > set_pmd_migration_entry() so it is easier to understand, and adds some > comments to make things clearer. > > I was able to bisect this to commit 775465fd26a3 ("lib/test_hmm: add zone > device private THP test infrastructure") which first exposes this bug as it > was the commit that permitted test_hmm to generate the test. > > However commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support > device-private entries") is the commit that actually enabled this > behaviour. > > Fixes: 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") > Cc: stable@vger.kernel.org > Signed-off-by: Lorenzo Stoakes LGTM, Reviewed-by: Oscar Salvador (SUSE) -- Oscar Salvador SUSE Labs