On Wed, Jun 03, 2026, Maximilian Senftleben wrote: > Hi, > > sorry for the late reply, took me a while to first built the kernel with > that options and then actually find time to play long enough. > > If I did everything correctly, then I build 7.0.7 with > - CONFIG_VMAP_STACK=y > - CONFIG_KASAN=y > > I did not get it to crash on that built kernel yet, however I booted > 7.0.9+deb14-amd64 once, and after playing a while got a crash again. > > I will try using the built kernel next week to see if I can get it to crash > as well.
Hmm, can you try 7.0.9 with KASAN? Or even just a 7.0.9 kernel that you built? It's possible there's a bug somewhere between 7.0.7 and 7.0.9. > Or do I have to look somewhere else if kasan is active? KASAN reports issues in dmesg. But generally speaking, if the error is bad enough to crash the kernel, you'll see a KASAN splat *and* a crash. > On 18.05.26 15:43, Sean Christopherson wrote: > > Odds are very good this is due to host memory corruption, and is not a bug > > in > > KVM's MMU. We (Google) had a period of time where our kernel was > > triggering stack > > overflows if a networking IRQ hit at just the right/wrong time, and > > whenever the > > overflow wandered into KVM page tables, it would result in failures like > > these. > > I got quite familiar with the signature :-) > Not sure if it could be something else, however I at least run memtest for > ~12h without problems. > > If you aren't already, can you try running with CONFIG_VMAP_STACK=y? Stack > > overflow doesn't seem likely in this case since the gfn would put the SPTE > > in the > > middle of the page table, but it's easy enough to rule out. > > > > The other thing to try would be to run with CONFIG_KASAN=y. That might > > make your > > gaming quite miserable, but if this is indeed due to a rogue write, it's > > the best > > shot for catching the culprit. > > > Regards >
