From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (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 17DAC3A7F40 for ; Tue, 2 Jun 2026 06:32:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780381949; cv=none; b=sGoQ3hld7+mS23sWEl6TlXvW5gO6mLjRrs2cqEHmCiROJSGKMuSPh2rExVl33R4V6jJBuilhtX0+OSfiJWBjHTfbitAIgm0YjkTKC8/nrkV6l7QdQ2kURNieaya6rioJky9hhbeJreoxwafePeK1z6hmP7zZPwtNPLceKjb8cW8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780381949; c=relaxed/simple; bh=C8INKOkezGzlnAsTDPrgZG7buknJtYQLVmYic3O2AXw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Ik8CvOmnsTYaB7swteTzp7evJbE8pzH/KV58N9Qt/RWoh/qd12U8vwqJvHyZSM77F46fSnbroYywzSeWY7a0bEq0ei6Fjk+HgV4B61sHQqKhCeiCqWx7gJ1oUi1ogLuCd0/tJqFpdfOBWHxHPepdc/Skans3db6RbC6yRITq/eE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=n+NdQY2K; arc=none smtp.client-ip=91.218.175.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="n+NdQY2K" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780381945; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C/Wy1IaJuFs/X0HLx0N3cZ8cEkjx/rrhoBDMvbNGsvI=; b=n+NdQY2KQ2wCk4EXY3Jjd3A9TjbnlM8MS4gVU6aQxCfZ+0CKTK+/y2/6+wl8ayOUd/gQcK ayf9t5X+d3I4u+SQtW6B6jm9ggSaBvBDGwgNLLz0+RWoYhGH0OY/uakHguv3SnzxK24Tk8 Bqzuk7SiuR8Mlz2r/uF1M/MaPHOaGG0= Date: Tue, 2 Jun 2026 14:32:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH mm-hotfixes] mm/huge_memory: use correct flags for device private PMD entry Content-Language: en-US To: Lorenzo Stoakes Cc: David Hildenbrand , Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Andrew Morton , Ryan Roberts , Dev Jain , Barry Song , SeongJae Park , Balbir Singh , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260601083044.57132-1-ljs@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20260601083044.57132-1-ljs@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2026/6/1 16:30, 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 > --- Cool, lesson learned! Feel free to add: Reviewed-by: Lance Yang