> On Apr 7, 2019, at 2:23 AM, Thomas Gleixner <t...@linutronix.de> wrote: > >> On Sat, 6 Apr 2019, Andy Lutomirski wrote: >> I haven't spotted the actual bug yet, but the faulting instruction is: >> >> 2a: 65 8b 35 09 ca 75 63 mov %gs:*0x6375ca09(%rip),%esi >> # 0x6375ca3a <-- trapping instruction >> >> This seems to be faulting just above the top of the stack (the thing >> in RSP), so I suspect that there is some path that is shoving the >> remapped value into GSBASE, which is wrong. >> >> Also, FWIW, there was some reason that I initialized all the virtual >> mappings for all possible CPUs early. I don't remember what it was, >> and it may not have been a good reason, but I put at least some >> nonzero amount of thought into it :) > > There is absolutely no reason to have irq stacks before init_IRQ(). 32bit > uses at runtime allocated irq stacks for years. > > If the CPU takes a device interrupt before that, then there are way more > things which explode than just the irqstack pointer being NULL. >
Fair enough. Although the patch I emailed in the other thread allows at least the entry code to survive on 64-bit at the cost of just a couple lines of code. But the kernel does indeed seem to work fine without the change. Feel free to disregard that part :)
