arch/x86/mm/pat/set_memory.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 453e7859443446b837d905d6f2983a76c867247d
Gitweb: https://git.kernel.org/tip/453e7859443446b837d905d6f2983a76c867247d
Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
AuthorDate: Thu, 13 Aug 2026 12:01:28 +03:00
Committer: Dave Hansen <dave.hansen@linux.intel.com>
CommitterDate: Tue, 01 Sep 2026 15:03:18 -07:00
x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr()
lookup_address_in_pgd_attr() accumulates the effective NX and RW bits of
the walked page table levels so that verify_rwx() can detect mappings that
are both writable and executable.
The RW bits are folded into a bool with
rw &= pXd_flags(*pXd) & _PAGE_RW;
but _PAGE_RW is 0x2. So consider the accumulation line:
rw &= pXd_flags(*pXd) & _PAGE_RW;
where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing:
rw = 0x1 & 0x2
and rw always ends up 0.
This way rw becomes false at the first level walked, regardless of the
actual permissions, and verify_rwx() treats every mapping as non-writable
and never reports a W^X violation.
Add double negation to the right side to normalize the _PAGE_RW flag to
0 or 1.
Assisted-by: Copilot:claude-opus-4.8
Fixes: ceb647b4b529 ("x86/pat: Introduce lookup_address_in_pgd_attr()")
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Tested-by: syzbot@syzkaller.appspotmail.com
Tested-by: Atish Patra <atishp@meta.com>
Tested-by: Nikunj A Dadhania <nikunj@amd.com>
Cc:stable@vger.kernel.org
Link: https://patch.msgid.link/20260813-cpa-fixes-v2-5-39b4ff90f91d@kernel.org
---
arch/x86/mm/pat/set_memory.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 4652487..2266609 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -754,7 +754,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
*level = PG_LEVEL_512G;
*nx |= pgd_flags(*pgd) & _PAGE_NX;
- *rw &= pgd_flags(*pgd) & _PAGE_RW;
+ *rw &= !!(pgd_flags(*pgd) & _PAGE_RW);
p4d = p4d_offset(pgd, address);
if (p4d_none(*p4d))
@@ -765,7 +765,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
*level = PG_LEVEL_1G;
*nx |= p4d_flags(*p4d) & _PAGE_NX;
- *rw &= p4d_flags(*p4d) & _PAGE_RW;
+ *rw &= !!(p4d_flags(*p4d) & _PAGE_RW);
pud = pud_offset(p4d, address);
if (pud_none(*pud))
@@ -776,7 +776,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
*level = PG_LEVEL_2M;
*nx |= pud_flags(*pud) & _PAGE_NX;
- *rw &= pud_flags(*pud) & _PAGE_RW;
+ *rw &= !!(pud_flags(*pud) & _PAGE_RW);
pmd = pmd_offset(pud, address);
if (pmd_none(*pmd))
@@ -787,7 +787,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
*level = PG_LEVEL_4K;
*nx |= pmd_flags(*pmd) & _PAGE_NX;
- *rw &= pmd_flags(*pmd) & _PAGE_RW;
+ *rw &= !!(pmd_flags(*pmd) & _PAGE_RW);
return pte_offset_kernel(pmd, address);
}Hi folks,
On Wed, Sep 02, 2026 at 06:33:31PM -0000, tip-bot2 for Mike Rapoport (Microsoft) wrote:
> The following commit has been merged into the x86/urgent branch of tip:
>
> Commit-ID: 453e7859443446b837d905d6f2983a76c867247d
> Gitweb: https://git.kernel.org/tip/453e7859443446b837d905d6f2983a76c867247d
> Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
> AuthorDate: Thu, 13 Aug 2026 12:01:28 +03:00
> Committer: Dave Hansen <dave.hansen@linux.intel.com>
> CommitterDate: Tue, 01 Sep 2026 15:03:18 -07:00
>
> x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr()
>
> lookup_address_in_pgd_attr() accumulates the effective NX and RW bits of
> the walked page table levels so that verify_rwx() can detect mappings that
> are both writable and executable.
>
> The RW bits are folded into a bool with
>
> rw &= pXd_flags(*pXd) & _PAGE_RW;
>
> but _PAGE_RW is 0x2. So consider the accumulation line:
>
> rw &= pXd_flags(*pXd) & _PAGE_RW;
>
> where rw=0x1 and the right side evaluates down to 0x2. It'll end up doing:
>
> rw = 0x1 & 0x2
>
> and rw always ends up 0.
>
> This way rw becomes false at the first level walked, regardless of the
> actual permissions, and verify_rwx() treats every mapping as non-writable
> and never reports a W^X violation.
>
> Add double negation to the right side to normalize the _PAGE_RW flag to
> 0 or 1.
>
> Assisted-by: Copilot:claude-opus-4.8
> Fixes: ceb647b4b529 ("x86/pat: Introduce lookup_address_in_pgd_attr()")
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> Tested-by: syzbot@syzkaller.appspotmail.com
> Tested-by: Atish Patra <atishp@meta.com>
> Tested-by: Nikunj A Dadhania <nikunj@amd.com>
> Cc:stable@vger.kernel.org
> Link: https://patch.msgid.link/20260813-cpa-fixes-v2-5-39b4ff90f91d@kernel.org
> ---
> arch/x86/mm/pat/set_memory.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index 4652487..2266609 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -754,7 +754,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
>
> *level = PG_LEVEL_512G;
> *nx |= pgd_flags(*pgd) & _PAGE_NX;
> - *rw &= pgd_flags(*pgd) & _PAGE_RW;
> + *rw &= !!(pgd_flags(*pgd) & _PAGE_RW);
>
> p4d = p4d_offset(pgd, address);
> if (p4d_none(*p4d))
> @@ -765,7 +765,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
>
> *level = PG_LEVEL_1G;
> *nx |= p4d_flags(*p4d) & _PAGE_NX;
> - *rw &= p4d_flags(*p4d) & _PAGE_RW;
> + *rw &= !!(p4d_flags(*p4d) & _PAGE_RW);
>
> pud = pud_offset(p4d, address);
> if (pud_none(*pud))
> @@ -776,7 +776,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
>
> *level = PG_LEVEL_2M;
> *nx |= pud_flags(*pud) & _PAGE_NX;
> - *rw &= pud_flags(*pud) & _PAGE_RW;
> + *rw &= !!(pud_flags(*pud) & _PAGE_RW);
>
> pmd = pmd_offset(pud, address);
> if (pmd_none(*pmd))
> @@ -787,7 +787,7 @@ pte_t *lookup_address_in_pgd_attr(pgd_t *pgd, unsigned long address,
>
> *level = PG_LEVEL_4K;
> *nx |= pmd_flags(*pmd) & _PAGE_NX;
> - *rw &= pmd_flags(*pmd) & _PAGE_RW;
> + *rw &= !!(pmd_flags(*pmd) & _PAGE_RW);
>
> return pte_offset_kernel(pmd, address);
> }
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.
[Sep 4 21:36] CPA detected W^X violation: 8000000000000123 -> 0000000000000123 range: 0xffffffffc0400000 - 0xffffffffc0400fff PFN 100e00
[ +0.000001] WARNING: arch/x86/mm/pat/set_memory.c:722 at __change_page_attr_set_clr+0xde7/0x1290, CPU#0: swapper/0/0
[ +0.000005] Modules linked in:
[ +0.000002] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc1-debug-00006-g453e78594434 #1 PREEMPT(full) 2950d432dd3910251071a66f3134fe0875432786
[ +0.000001] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1801 12/26/2022
[ +0.000001] RIP: 0010:__change_page_attr_set_clr+0xdff/0x1290
[ +0.000002] Code: 80 7c 24 42 00 0f 85 3a 04 00 00 48 8d 3d 19 8d 79 02 49 89 d9 4c 89 e1 4c 89 d2 4c 89 f6 4d 8d 84 24 ff 0f 00 00 4c 89 14 24 <67> 48 0f b9 3a 4c 8b 14 24 48 8b 0d 81 44 bf 01 41 f6 c2 01 0f 85
[ +0.000001] RSP: 0000:ffffffff87003c60 EFLAGS: 00010246
[ +0.000002] RAX: 0000000000000002 RBX: 0000000000100e00 RCX: ffffffffc0400000
[ +0.000000] RDX: 0000000000000123 RSI: 8000000000000123 RDI: ffffffff872e50c0
[ +0.000001] RBP: 8000000100e00123 R08: ffffffffc0400fff R09: 0000000000100e00
[ +0.000001] R10: 0000000000000123 R11: 0000000000000001 R12: ffffffffc0400000
[ +0.000000] R13: 0000000100e00123 R14: 8000000000000123 R15: ffffffff87003d58
[ +0.000001] FS: 0000000000000000(0000) GS:ffff8ad1777a7000(0000) knlGS:0000000000000000
[ +0.000001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000001] CR2: ffff8ad0a4201000 CR3: 00000007e3022001 CR4: 0000000000770ef0
[ +0.000001] PKRU: 55555554
[ +0.000001] Call Trace:
[ +0.000001] <TASK>
[ +0.000002] ? _vm_unmap_aliases+0x219/0x280
[ +0.000003] change_page_attr_set_clr+0x161/0x250
[ +0.000002] ? events_sysfs_show+0x5d/0x80
[ +0.000002] set_memory_x+0x39/0x50
[ +0.000002] apply_retpolines+0x656/0x6d0
[ +0.000002] ? events_sysfs_show+0x5d/0x80
[ +0.000002] ? events_sysfs_show+0x6c/0x80
[ +0.000001] ? events_sysfs_show+0x62/0x80
[ +0.000001] alternative_instructions+0x3c/0xd0
[ +0.000003] arch_cpu_finalize_init+0x130/0x190
[ +0.000003] start_kernel+0x97d/0xa10
[ +0.000002] x86_64_start_reservations+0x24/0x30
[ +0.000002] x86_64_start_kernel+0xda/0xe0
[ +0.000002] common_startup_64+0x13e/0x151
[ +0.000003] </TASK>
[ +0.000001] ---[ end trace 0000000000000000 ]---
# bad: [af5f12805e5cefa4fe68d6127c7e1fb78cd5535c] Add linux-next specific files for 20260904
# good: [421066905cbceca1f78cba5f7d92b4980317ab2b] Merge tag 'probes-fixes-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
git bisect start 'af5f12805e5cefa4fe68d6127c7e1fb78cd5535c' '421066905cbceca1f78cba5f7d92b4980317ab2b'
# bad: [7e9b8247e9129fa3803020d3262e2384a0cfc29a] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
git bisect bad 7e9b8247e9129fa3803020d3262e2384a0cfc29a
# bad: [c4faef7e83f9c601c1264c0fad20af0e00b5a52b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
git bisect bad c4faef7e83f9c601c1264c0fad20af0e00b5a52b
# good: [14bd0d1671d1655d33419b60c9c476d0590636dd] Merge branch 'drm-fixes' of https://gitlab.freedesktop.org/drm/kernel.git
git bisect good 14bd0d1671d1655d33419b60c9c476d0590636dd
# good: [8d6fa663f11a859304187a70c569ec0617aa2461] Merge https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable into for-next
git bisect good 8d6fa663f11a859304187a70c569ec0617aa2461
# bad: [276cefa1ab31a5d4fe5e4446f5e504499cc03320] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mm/linux.git
git bisect bad 276cefa1ab31a5d4fe5e4446f5e504499cc03320
# good: [aad09a60e0012e85b03540a12e1fd1a61646712b] Merge branch 'rust-fixes' of https://github.com/Rust-for-Linux/linux.git
git bisect good aad09a60e0012e85b03540a12e1fd1a61646712b
# bad: [586e57cb2f695099a15e72029804a0592e6ad566] Merge branch into tip/master: 'x86/urgent'
git bisect bad 586e57cb2f695099a15e72029804a0592e6ad566
# good: [223f1750ff141a7e59b2724b645f348ffdab12e9] Merge branch into tip/master: 'sched/urgent'
git bisect good 223f1750ff141a7e59b2724b645f348ffdab12e9
# good: [e679ba0983757e9567aeda97cc35c99241d420ee] x86/alternative: Exclude text poking against change_page_attr()
git bisect good e679ba0983757e9567aeda97cc35c99241d420ee
# bad: [453e7859443446b837d905d6f2983a76c867247d] x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr()
git bisect bad 453e7859443446b837d905d6f2983a76c867247d
# good: [0e33126d5def407397deaf617559a1a2a7f4b1ae] x86/mm/pat: Allocate split page tables as kernel page tables
git bisect good 0e33126d5def407397deaf617559a1a2a7f4b1ae
# first 'bad' commit: [453e7859443446b837d905d6f2983a76c867247d] x86/mm/pat: Fix effective RW computation in lookup_address_in_pgd_attr()
If there is any information I can provide to help debug this, I am happy
to provide it.
--
Cheers,
Nathan
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
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. its_pages_protect() should be fixing this up
at the end of things, so there would be no permanent harm just a
temporary violation of CONFIG_STRICT_MODULE_RWX.
Peter, shouldn't we be using the text poking mm for things like this?
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?
> 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
--
Cheers,
Nathan
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().
Anyway, I'm curious what Peter wants to do with this.
On Sun, Sep 06, 2026 at 12:12:54PM -0700, Dave Hansen wrote: > On 9/6/26 11:12, Nathan Chancellor wrote: > > 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. Ah okay, that parses way better. I assume this will be sorted out without further information needed from me but I am happy to test a patch when available. -- Cheers, Nathan
Hi Nathan, On Mon, Sep 07, 2026 at 03:28:13PM -0700, Nathan Chancellor wrote: > On Sun, Sep 06, 2026 at 12:12:54PM -0700, Dave Hansen wrote: > > On 9/6/26 11:12, Nathan Chancellor wrote: > > > 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. > > Ah okay, that parses way better. I assume this will be sorted out > without further information needed from me but I am happy to test a > patch when available. Here: https://lore.kernel.org/all/20260908092730.4002628-1-rppt@kernel.org/T/#u > -- > Cheers, > Nathan -- Sincerely yours, Mike.
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.
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.
© 2016 - 2026 Red Hat, Inc.