All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-11-07 19:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 11:38 [PATCH] mm: clear pmd in pmdp_invalidate() 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-11-08 10:22       ` Guilherme Giacomo Simoes
2026-11-09 12:52         ` David Hildenbrand (Arm)
2026-10-27 23:10 ` [syzbot ci] " syzbot ci
2026-10-28 11:38 ` [PATCH] " sashiko-bot

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 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.