On Fri, Jan 29, 2021 at 9:03 PM Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> wrote: > > pt., 29 sty 2021 o 19:59 Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> napisał(a): > > > > czw., 28 sty 2021 o 15:32 Marcin Ślusarz <marcin.slusarz@xxxxxxxxx> napisał(a): > > > > > > czw., 28 sty 2021 o 13:39 Rafael J. Wysocki <rafael@xxxxxxxxxx> napisał(a): > > > > The only explanation for that I can think about (and which does not > > > > involve supernatural intervention so to speak) is a stack corruption > > > > occurring between these two calls in sdw_intel_acpi_cb(). IOW, > > > > something scribbles on the handle in the meantime, but ATM I have no > > > > idea what that can be. > > > > > > I tried KASAN but it didn't find anything and kernel actually booted > > > successfully. > > > > I investigated this and it looks like a compiler bug (or something nastier), > > but I can't find where exactly registers get corrupted because if I add printks > > the corruption seems on the printk side, but if I don't add them it seems > > the value gets corrupted earlier. > (...) > > I'm using gcc 10.2.1 from Debian testing. > > Someone on IRC, after hearing only that "gcc miscompiles the kernel", > suggested disabling CONFIG_STACKPROTECTOR_STRONG. > It helped indeed and it matches my observations, so it's quite likely it > is the culprit. > > What do we do now? Figure out why the stack protection kicks in, I suppose. The target object is not on the stack, so if the pointer to it is valid (we need to verify somehow that it is indeed), dereferencing it shouldn't cause the stack protection to trigger.
