Re: [Linux PPC] Disable PREEMPT

["Michal Suchánek" <msuchanek@suse.de>]

On Fri, Sep 11, 2026 at 10:39:10PM +0530, Shrikanth Hegde wrote:
> Hi Michal,
> 
> On 9/10/26 5:46 PM, Michal Suchánek wrote:
> > On Thu, Sep 10, 2026 at 01:29:08PM +0200, Michal Suchánek wrote:
> > > On Thu, Sep 10, 2026 at 04:11:20PM +0530, Shrikanth Hegde wrote:
> > > > 
> > > > 
> > > > On 9/10/26 2:29 PM, Michal Suchánek wrote:
> > > > > On Fri, Sep 04, 2026 at 02:34:21PM +0530, Shrikanth Hegde wrote:
> > > > > > 
> > > > > > 
> > > > > > On 9/4/26 1:05 PM, Michal Suchánek wrote:
> > > > > > > On Thu, Sep 03, 2026 at 10:52:59PM +0530, Shrikanth Hegde wrote:
> > > > > > > > 
> > > > > > > > > > If possible run against current upstream and share the results.
> > > > > > > > > 
> > > > > > > > > https://github.com/openSUSE/kernel-source/blob/6824496d1801f73def615dca8794202eeb7b0d86/config/ppc64le/default
> > > > > > > > > 
> > > > > > > > > [  472.091531][ T6181] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: kvmhv_run_single_vcpu+0x19d4/0x1b50 [kvm_hv]
> > > > > > > > > [  472.091598][ T6181] CPU: 29 UID: 107 PID: 6181 Comm: CPU 112/KVM Not tainted 7.2.2-5.g6824496-default #1 PREEMPT(full) openSUSE Tumbleweed (unreleased)  61871a5f06863b4006f5ef27cd9f18e8a7a2edad
> > > > > > > > > [  472.091612][ T6181] Hardware name: IBM,9824-42A Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.20 (OB1110_130) hv:phyp pSeries
> > > > > > > > > [  472.091624][ T6181] Call Trace:
> > > > > > > > > [  472.091630][ T6181] [c00000000fdfb680] [c00000000134ce90] dump_stack_lvl+0x84/0xc0 (unreliable)
> > > > > > > > > [  472.091653][ T6181] [c00000000fdfb6b0] [c00000000022e7c8] vpanic+0x324/0x5e4
> > > > > > > > > [  472.091666][ T6181] [c00000000fdfb760] [c00000000022eac4] do_panic_on_target_cpu+0x0/0x2c
> > > > > > > > > [  472.091677][ T6181] [c00000000fdfb780] [c0000000013c1ff8] __stack_chk_fail+0x48/0x60
> > > > > > > > > [  472.091689][ T6181] [c00000000fdfb7f0] [c00800001aae219c] kvmhv_run_single_vcpu+0x19d4/0x1b50 [kvm_hv]
> > > > > > > > > [  472.091712][ T6181] [c00000000fdfb940] [c00800001aae24b4] kvmppc_vcpu_run_hv+0x19c/0x12f0 [kvm_hv]
> > > > > > > > > [  472.091732][ T6181] [c00000000fdfba10] [c00800001aeeed18] kvmppc_vcpu_run+0x30/0x48 [kvm]
> > > > > > > > > [  472.091779][ T6181] [c00000000fdfba30] [c00800001aee9ef4] kvm_arch_vcpu_ioctl_run+0x35c/0x4a0 [kvm]
> > > > > > > > > [  472.091813][ T6181] [c00000000fdfbac0] [c00800001aedaac4] kvm_vcpu_ioctl+0x1ac/0xad8 [kvm]
> > > > > > > > > [  472.091844][ T6181] [c00000000fdfbca0] [c0000000007f1244] sys_ioctl+0x374/0x1060
> > > > > > > > > [  472.091857][ T6181] [c00000000fdfbdb0] [c00000000002f7f8] system_call_exception+0x188/0x430
> > > > > > > > > [  472.091871][ T6181] [c00000000fdfbe50] [c00000000000cfdc] system_call_vectored_common+0x15c/0x2ec
> > > > > > > > > [  472.091886][ T6181] ---- interrupt: 3000 at 0x7fffb5565fac
> > > > > > > > > [  472.091896][ T6181] NIP:  00007fffb5565fac LR: 00007fffb5565fac CTR: 0000000000000000
> > > > > > > > > [  472.091904][ T6181] REGS: c00000000fdfbe80 TRAP: 3000   Not tainted  (7.2.2-5.g6824496-default)
> > > > > > > > > [  472.091911][ T6181] MSR:  800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE>  CR: 42044402  XER: 00000000
> > > > > > > > > [  472.091938][ T6181] IRQMASK: 0
> > > > > > > > > [  472.091938][ T6181] GPR00: 0000000000000036 00007fbfa77ed7a0 00007fffb5677100 00000000000000fa
> > > > > > > > > [  472.091938][ T6181] GPR04: 000000002000ae80 0000000000000000 0000000000000000 0000000000000000
> > > > > > > > > [  472.091938][ T6181] GPR08: 00000000000000fa 0000000000000000 0000000000000000 0000000000000000
> > > > > > > > > [  472.091938][ T6181] GPR12: 0000000000000000 00007fbfa77f5ec0 000000014676f000 00007fbfa77ee7c0
> > > > > > > > > [  472.091938][ T6181] GPR16: 000000014674e8d0 00007fbfa77eeec0 00007fbfa77eeec0 fffffffffffffff7
> > > > > > > > > [  472.091938][ T6181] GPR20: 00007fffb71210d0 0000000000000001 00007fbfa77eeec0 0000000000000000
> > > > > > > > > [  472.091938][ T6181] GPR24: 00007fbfa77ed8e8 0000000105971428 000000002000ae80 0000000105f77a70
> > > > > > > > > [  472.091938][ T6181] GPR28: 0000000000000000 0000000000000000 000000002000ae80 000000014674f000
> > > > > > > > > [  472.092020][ T6181] NIP [00007fffb5565fac] 0x7fffb5565fac
> > > > > > > > > [  472.092027][ T6181] LR [00007fffb5565fac] 0x7fffb5565fac
> > > > > > > > > [  472.092033][ T6181] ---- interrupt: 3000
> > > > > > > > > [  472.098256][ T6181] pstore: backend (nvram) writing error (-1)
> > > > > > > > > 
> > > > > > > > > This is the host, cannot run the kernel as guest because it fails to boot most
> > > > > > > > > of the time inside KVM.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > Nonethless, there are quite a few platforms. Originally no preemption
> > > > > > > > > > > was the only option, and that's the reason why many people run that.
> > > > > > > > > > > It's the conservative, known working option. And that's the reason a lot
> > > > > > > > > > > of platfrom code does not get tested with more aggressive preemtion
> > > > > > > > > > > models, and never gets fixed to work with them.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Full preemption has been there for many years!.
> > > > > > > > > 
> > > > > > > > > Possible for years, forced only recently.
> > > > > > > > > 
> > > > > > > > > > Lazy is not that aggressive compared to that.
> > > > > > > > > > 
> > > > > > > > > > > Simply disabling the no preemtion option does not make the platform code
> > > > > > > > > > > ready.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Let's understand your crash case. Let's see where it is going wrong. I am suspecting
> > > > > > > > > > it is some wrong usage of preemption api rather than arch can't support preemption.
> > > > > > > > > 
> > > > > > > > > Very likely some wrong use of the preemption API by the arch code, or no
> > > > > > > > > use where it should have been used. It did not matter so long as people
> > > > > > > > > could run their no preempt configs and ignore the problem.
> > > > > > > > > 
> > > > > > > > > Thanks
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Friendly LLM analysis says preemption is enabled too early and before
> > > > > > > > completing kvmppc_handle_exit_hv() / kvmppc_handle_nested_exit()
> > > > > > > > 
> > > > > > > > Below is ONLY a speculation and completely UNTESTED.
> > > > > > > > Maybe worth a try.
> > > > > > > 
> > > > > > > The patch is munged by the e-mail client, and it causes immediate
> > > > > > > voluntary preemprion in rcu critical section and hard lockup on starting
> > > > > > > a KVM VM.
> > > > > > > 
> > > > > > > Also it would be sort of bad news if it worked because that would be
> > > > > > > specific to book3s KVM HV and would not help with the KVM HV from the
> > > > > > > original report which likely is not book3s, nor with KVM PR.
> > > > > > > 
> > > > > > 
> > > > > > Thanks for trying. We will try a local repro and look into it why stack is
> > > > > > getting corrupted.
> > > > > 
> 
> As we discussed offlist, samir helped to run a similar test on his machine, and he didn't
> run into issue so far. we will try more.
> 
> I am just wondering what different in your case?
> By any chance we are running into below one? Can you check your gcc version?
> 
> https://lore.kernel.org/all/CAABZP2z=xu+07-y5fqFLidZz1VpSgrSwXa1mFHPb=b3Ezr3OtA@mail.gmail.com/
> 
> Maybe CONFIG_DEBUG_PREEMPT worth a try to if it shows up anything.

Does not change anything, the kernel crashes all the same.

Nonetheless, I noticed that a tool that does some BPF tracing is
running, and without it the problem is not reproducible.

Thanks

Michal