Re: [tip: x86/urgent] x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr()

[Mike Rapoport]

On Sun, Sep 06, 2026 at 12:12:54PM -0700, Dave Hansen wrote:
> On 9/6/26 11:12, Nathan Chancellor wrote:
> > On Sun, Sep 06, 2026 at 07:50:26AM -0700, Dave Hansen wrote:
> >> On 9/4/26 21:42, Nathan Chancellor wrote:
> >>> I just bisected the following warning on a couple of my test machines to
> >>> commit 453e78594434 ("x86/mm/pat: Fix effective RW computation in
> >>> lookup_address_in_pgd_attr()") in next-20260904.
> >> ...
> >>> If there is any information I can provide to help debug this, I am happy
> >>> to provide it.
> >>
> >> Well, the thing you bisected to is the patch that fixes the warning. The
> > 
> > Hmmm, I don't see a warning prior to this patch though. Do you mean that
> > this patch is just revealing the bad behavior that you mention below?
> 
> Yeah, "fixes" was a bad word to use.
> 
> The W^X detection has been broken for a while. The patch you bisected to
> fixes the W^X detection. It doesn't actually cause the issue.
> 
> >> actual issue comes from:
> >>
> >>         if (pages == &its_pages)
> >>                 set_memory_x((unsigned long)page, 1);
> >>
> >> which its_alloc() does on an execmem allocation. Any chance you could
> >> get the output of:
> >>
> >> 	/sys/kernel/debug/page_tables/current_kernel
> >>
> >> for the page that page that it's complaining about? I'm curious if this
> >> is temporary or permanent.
> > 
> > Sure. For
> > 
> >    CPA detected W^X violation: 8000000000000123 -> 0000000000000123 range: 0xffffffffc0200000 - 0xffffffffc0200fff PFN 100e00
> > 
> > I think it is this line if I understand correctly?
> > 
> >   0xffffffffc0200000-0xffffffffc0400000           2M     ro         PSE     GLB x  pmd
> 
> Yeah, that does seems to show it getting fixed up. Thanks! That means
> that the warning (at least in early boot) is essentially a false
> positive. The problem is that there's module-load-time patching too and
> that is much later and is arguably an actual problem.
> 
> Oh, and thinking about it a bit more... This warning came from
> alternatives patching which is too early for normal text_poke(), thus
> the existence of text_poke_early().

But text_poke_early is a memcpy :)

The warning at core text patching is completely spurious because anyway the
entire kernel text is mapped as RWX at that point.

This one should be fixed as with the patch below. As for the modules,
text_poke()ing sounds like the way to move forward and ...

> Anyway, I'm curious what Peter wants to do with this.

... I'm also curious what Peter will suggest :)

diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index c38faf39ce152..42ea8b4234b82 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -686,6 +686,10 @@ static inline pgprot_t verify_rwx(pgprot_t old, pgprot_t new, unsigned long star
 	if (!(__supported_pte_mask & _PAGE_NX))
 		return new;
 
+	/* skip verification until kernel text is set to read only */
+	if (!kernel_set_to_readonly)
+		return new;
+
 	if (!((pgprot_val(old) ^ pgprot_val(new)) & (_PAGE_RW | _PAGE_NX)))
 		return new;
 
 

-- 
Sincerely yours,
Mike.