From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com>
Cc: akpm@linux-foundation.org, liam@infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org,
mhocko@suse.com, rppt@kernel.org, surenb@google.com,
vbabka@kernel.org
Subject: Re: [PATCH] mm: clear pmd in pmdp_invalidate()
Date: Sat, 7 Nov 2026 20:28:56 +0100 [thread overview]
Message-ID: <bf5c4e81-2c9c-4f4a-ae7c-9edf6a524d1a@kernel.org> (raw)
In-Reply-To: <20261104111254.320059-1-trintaeoitogc@gmail.com>
On 11/4/26 12:12, Guilherme Giacomo Simoes wrote:
> David, I haved immersed inside this problem on last days, and how sashiko-bot
> very well apointed, I'm haved doing a wrong duplicated clear on pmd's. I not
> notice that the pmd_establish() already called the page_table_check_pmd_set()
> wich in turn call __page_table_check_pmd_clear(), my bad.
>
> At first time, I thinked the problem is a duplicated
> page_table_check_pmd_set(), but with a LLM helpful I ruled out this hypothesis,
> because I not found any obvious call to page_table_check_pmd_set() before
> remove_migration_pte(). At second time, I suspicious that maybe we are haved a
> race condition, that make no sense...
>
> After a lot of debug and tests, I found a thing.. And I attempt to test this.
> If you see inside arch/riscv/include/asm/pgtable.h, the pmd_mkinvalid() do:
> ```
> static inline pmd_t pmd_mkinvalid(pmd_t pmd)
> {
> return __pmd(pmd_val(pmd) & ~(_PAGE_PRESENT|_PAGE_PROT_NONE));
> }
> ```
>
> but , the pmd_user_accessible_page() check `pmd_leaf(pmd) && pmd_user(pmd);`
> and pmd_leaf():
> ```
> static inline bool pmd_leaf(pmd_t pmd)
> {
> return pmd_present(pmd) && (pmd_val(pmd) & _PAGE_LEAF);
> }
> ```
>
> and the pmd_present():
> ```
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> static inline int pmd_present(pmd_t pmd)
> {
> /*
> * Checking for _PAGE_LEAF is needed too because:
> * When splitting a THP, split_huge_page() will temporarily clear
> * the present bit, in this situation, pmd_present() and
> * pmd_trans_huge() still needs to return true.
> */
> return (pmd_val(pmd) & (_PAGE_PRESENT | _PAGE_PROT_NONE | _PAGE_LEAF));
> }
> #else
> static inline int pmd_present(pmd_t pmd)
> {
> return (pmd_val(pmd) & (_PAGE_PRESENT | _PAGE_PROT_NONE));
> }
> #endif
> ```
>
> And the TRANSPARENT HUGE PAGE , is exactly a page that I was allocated with
> mmap() (see my previous emails with my repro.c).
>
> So, I change the pmd_mkinvalid() adding PAGE_LEAF flag:
> ```
> static inline pmd_t pmd_mkinvalid(pmd_t pmd)
> {
> return __pmd(pmd_val(pmd) & ~(_PAGE_PRESENT|_PAGE_PROT_NONE|_PAGE_LEAF));
> }
> ```
>
> And this work for my repro.c.
> The problem here is what the documentation of pmd_present() say:
> ```
> /*
> * Checking for _PAGE_LEAF is needed too because:
> * When splitting a THP, split_huge_page() will temporarily clear
> * the present bit, in this situation, pmd_present() and
> * pmd_trans_huge() still needs to return true.
> */
> ```
>
> So the documentation say that if a THP is splitting, this should return true
> event though PAGE_PRESENT and PAGE_PROT_NONE is cleared.
> If you think about this, maybe make sense.
>
> And after some searchs I saw that was already fixed by Yunhui Cui
> <cuiyunhui@bytedance.com>
> https://lore.kernel.org/all/20260523042052.35476-1-cuiyunhui@bytedance.com/
I remember that Zi is currently also fixing some pmd_mkinvalid() implementations.
Is there anything to fix from your side, or does the above fix already resolve
your problem?
--
Cheers,
David
next prev parent reply other threads:[~2026-11-07 19:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 11:38 Guilherme Giacomo Simoes
2026-10-27 12:11 ` David Hildenbrand (Arm)
2026-10-27 14:09 ` Guilherme Giacomo Simoes
2026-10-27 14:50 ` Guilherme Giacomo Simoes
2026-11-04 11:12 ` Guilherme Giacomo Simoes
2026-11-07 19:28 ` David Hildenbrand (Arm) [this message]
2026-10-27 23:10 ` [syzbot ci] " syzbot ci
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=bf5c4e81-2c9c-4f4a-ae7c-9edf6a524d1a@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=trintaeoitogc@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®