From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Samarth Narang <samarth.colleges@gmail.com>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
akpm@linux-foundation.org, liam@infradead.org,
vbabka@kernel.org, jannh@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mm/madvise: keep the hardware dirty bit in MADV_COLD's THP path
Date: Mon, 12 Oct 2026 21:00:51 +0100 [thread overview]
Message-ID: <as08NnPG1AF2cG1Z@gremlin> (raw)
In-Reply-To: <CAAbz3fTZyeDL1Sy5FOxuJ8e0zgM5SJa1UKa7sk2apkaJFeeBaA@mail.gmail.com>
On Mon, Oct 12, 2026 at 02:25:38PM -0400, Samarth Narang wrote:
> Thanks both for your review into this; I was building a structural detector
> tool over page-table bit paths, and came across this.
> I got agents to reproduce it on x86 where we mark a 2MiB anon THP
> MADV_FREE, race a store from a second CPU against MADV_COLD, then force
> reclaim with MADV_PAGEOUT. The race pass loses stores while the control
> pass does not.
>
> Based on your suggestion, can we clear the accessed bit in place with
> pmdp_test_and_clear_young(), as the PTE path does via
> ptep_test_and_clear_young(), instead of rebuilding the entry from
> pmdb_invalidate()'s return value. I tried this patch on the bug, and the
> fix holds. Let me know what you think.
As I already told you, this is being handled by a member of the core team,
thanks.
--
Cheers, Lorenzo
prev parent reply other threads:[~2026-10-12 20:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 13:22 [PATCH] mm/madvise: keep the hardware dirty bit in MADV_COLD's THP path samarth.colleges
2026-10-12 10:00 ` Lorenzo Stoakes (ARM)
2026-10-12 10:09 ` David Hildenbrand (Arm)
2026-10-12 10:33 ` Lorenzo Stoakes (ARM)
2026-10-12 10:38 ` Lorenzo Stoakes (ARM)
2026-10-12 15:17 ` Zi Yan
2026-10-12 15:26 ` Lorenzo Stoakes (ARM)
2026-10-12 19:02 ` Pedro Falcato
2026-10-12 18:25 ` Samarth Narang
2026-10-12 20:00 ` Lorenzo Stoakes (ARM) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as08NnPG1AF2cG1Z@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=samarth.colleges@gmail.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.