Re: [PATCH 0/5] x86/mm/pat: CPA fixes

[Pedro Falcato]

 On Thu, Jul 30, 2026 at 05:53:50PM +0200, Steffen Dirkwinkel wrote:
> Hello,
> 
> 
> On Tue, 2026-07-28 at 16:07 +0300, Mike Rapoport (Microsoft) wrote:
> > There are a couple of CPA fixes floating around:
> > 
> > Denis Lunev fixed races between split and collapse of the large mappings:
> > 
> > https://lore.kernel.org/all/20260715183453.2381141-1-den@xxxxxxxxxx
> 
> We saw the error below and I was wondering if it might be related to these fixes
> or a similar case that's unfixed still. Seems to have happened during concurrent
> kernel module loading of kvm and i915 (similar to the case in the patch from
> Denis Lunev). But we got it without KASAN and the stack looks a little
> different. I was not able to reproduce this with a ~16 hour concurrent module
> load unload loop so far.
> 
> Kernel: v7.1.5, PREEMPT_RT, tainted because of /dev/msr access
> CPU: Elkhart Lake Atom X6214RE, 2 cores, isolcpus=1-N
> 
> ------------[ cut here ]------------
> kernel BUG at arch/x86/kernel/alternative.c:2644!
> Oops: invalid opcode: 0000 [#1] SMP NOPTI
> CPU: 0 UID: 0 PID: 559 Comm: (udev-worker) Tainted: G S                  7.1.5-
> rt1-bhf-369933-f1a4ee1dd787 #1 PREEMPT_{RT,(lazy)} 
> Tainted: [S]=CPU_OUT_OF_SPEC
> RIP: 0010:__text_poke+0x356/0x3d0
> Call Trace:
>  <TASK>
>  smp_text_poke_batch_finish+0x1aa/0x3a0
>  ? vmx_switch_vmcs+0xc8/0xd0 [kvm_intel]
>  __static_call_transform+0xfa/0x1f0
>  ? vmx_switch_vmcs+0xc8/0xd0 [kvm_intel]
>  ? __pfx_preempt_schedule_thunk+0x10/0x10
>  arch_static_call_transform+0x57/0xa0
>  ? vmx_switch_vmcs+0xc8/0xd0 [kvm_intel]
>  __static_call_init+0x1aa/0x230
>  ? __SCT__tp_func_kvm_mmu_split_huge_page+0x8/0x8
>  ? __SCT__tp_func_kvm_mmu_split_huge_page+0x8/0x8
>  static_call_module_notify+0x11f/0x150

We're also observing something very similar downstream
(https://bugzilla.opensuse.org/show_bug.cgi?id=1271202) on 7.1.3 kernels, on our QA infra.

I wrote a patch that should fix it (I didn't get to test it yet, since
this didn't hit mainline/stable yet), on top of this. Mike, do you mind
throwing it on top of this series, or should I submit separately?

-- 
Pedro