[PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> > So it's either unwinder related, or seemingly minor changes to code 
> > alignment/placement will make the bug go away.
> 
> Ok, I think the Orc unwinder is innocent: I just forced a build with frame 
> pointers but with ORC debuginfo and unwinder, and that is booting fine too.
> 
> So it's the specific code size and alignment present in the config I sent that is 
> triggering the bug. Fudging that alignment/sizing with the workaround patch above 
> makes the crash go away.

Ok, after a few hours of debugging with Thomas today we found the bug: it was 
caused by Kaiser not mapping the __irqentry_text_start...__irqentry_text_end 
kernel virtual memory range, which the IRQ entry code requires before it switches 
to the kernel page tables.

This bug was hidden in most configs by virtue of:

 	kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
 				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);

because the __irqentry_text_start...__irqentry_text_end kernel code section comes 
right after this section and is pretty small - so it usually fits into the last 
page of the mapping.

But for certain configs the __entry_text_start address crossed the next page 
boundary, and was not mapped - resulting in a page fault and then in a double 
fault as the entry stack overflowed.

The patch below fixes the crash, and after some testing I'll backmerge it to the 
core Kaiser patch in tip:WIP.x86/mm.

There's a few takeaways from this incident though:

 - Entry stack overflow debugging is pretty crude and should probably be improved.

 - We should better isolate all Kaiser-mapped sections and pad them out
   to page boundary. This would immediately trigger any simila false-sharing 
   side-effect mapping bugs and they wouldn't be .config dependent Heisenbugs.

Thanks,

	Ingo

=============>