From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (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 0B9F7367B63 for ; Tue, 2 Jun 2026 03:29:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780371001; cv=none; b=X7n5FLXf96vbLFe1/587WFp+UgXz7GVHbtArj1gXGKCxw6pC2X3Kr1mVC1MT/sIAP/WXvmgmb1qgxoVnI5HGoKCxMn243DYZevcPO3I2i7M56Gsjmhm+k1jemzozrpJZ3hXH6TAogyhFk2cdzmsRNrMI/xZDgKydqfKDUFJQol4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780371001; c=relaxed/simple; bh=qDfKV//Kq2ugQHySgrtg0ayRWdMBEA8A4iqtY/rMSMg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rmX+oILnmDPsKMCOTSNA6IcOLYfZj5oiTgWM3h1W8icwNyrMm7BBiHN5XFq5n/5iyn7SwBeIz7Xe/Y14SQ9kMJ07yLcsgzKh7mP6gNpwgOI6HCpf/tb1a3lMnY9SJlveVoWs9BECiZwnMn7dDgLAVHd9zmy3jmQopTQrY11objY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=SnZv1RUr; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="SnZv1RUr" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1780370995; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=coyOUsvaOjNin9zL0dWryXVgwBZsowpVXbprEgp4Mbw=; b=SnZv1RUr+aHlxJTSGO2+uyE2+uI/Uuu2dwZje9h36VeWKMnXBgHEnTqnQR1zbj+wMrIXDR6xOF26jPxdmFTlJ3+aG1Er/BZq6IIrnH5H1wObE5txLh71usp8CdDtjcHTTudVFIjZk6ldljLRx2cbJvKmLngzKvINtF8dt+P0rqg= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0X42n0-6_1780370993; Received: from 30.166.17.138(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X42n0-6_1780370993 cluster:ay36) by smtp.aliyun-inc.com; Tue, 02 Jun 2026 11:29:54 +0800 Message-ID: <964254f8-2b98-4540-9e00-3d07930bdb24@linux.alibaba.com> Date: Tue, 2 Jun 2026 11:29:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH mm-hotfixes] mm/huge_memory: use correct flags for device private PMD entry To: Lorenzo Stoakes , Andrew Morton Cc: David Hildenbrand , Zi Yan , "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 References: <20260601083044.57132-1-ljs@kernel.org> From: Baolin Wang In-Reply-To: <20260601083044.57132-1-ljs@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/1/26 4:30 PM, 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 > --- Thanks for your detailed explanation. Feel free to add: Reviewed-by: Baolin Wang