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 10:52:41PM +0300, Mike Rapoport wrote:
> 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 ...

For modules everything should just work, the memory is RW until
its_fini_mod() that resets to to ROX, so there are no RWX violations.

Looking at the code after morning coffee rather than near midnight helps :)

-- 
Sincerely yours,
Mike.