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

[Thomas Gleixner <tglx@linutronix.de>]

On Sat, 25 Nov 2017, Ingo Molnar wrote:
>  	kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
>  				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);
> +	kaiser_add_user_map_ptrs_early(__irqentry_text_start, __irqentry_text_end,
> +				       __PAGE_KERNEL_RX | _PAGE_GLOBAL);

The bad news is that this maps more stuff than actually needed:

ffffffff81ab1c20 T __irqentry_text_start
ffffffff81ab1c20 T apic_timer_interrupt
ffffffff81ab1cf0 T x86_platform_ipi
ffffffff81ab1dc0 T threshold_interrupt
ffffffff81ab1e90 T deferred_error_interrupt
ffffffff81ab1f60 T thermal_interrupt
ffffffff81ab2030 T call_function_single_interrupt
ffffffff81ab2100 T call_function_interrupt
ffffffff81ab21d0 T reschedule_interrupt
ffffffff81ab22a0 T error_interrupt
ffffffff81ab2370 T spurious_interrupt
ffffffff81ab2440 T irq_work_interrupt

The above are the real entry points. The below is already C-Code which has
nothing to do with the entry region.

ffffffff81ab2510 T do_IRQ
ffffffff81ab2610 T smp_x86_platform_ipi
ffffffff81ab2840 T smp_irq_work_interrupt
ffffffff81ab2a50 T smp_deferred_error_interrupt
ffffffff81ab2c60 T smp_threshold_interrupt
ffffffff81ab2e70 T smp_thermal_interrupt
ffffffff81ab3080 T smp_reschedule_interrupt
ffffffff81ab3280 T smp_call_function_interrupt
ffffffff81ab3490 T smp_call_function_single_interrupt
ffffffff81ab36a0 T smp_apic_timer_interrupt
ffffffff81ab3900 T smp_spurious_interrupt
ffffffff81ab3b40 T smp_error_interrupt
ffffffff81ab3e20 T smp_irq_move_cleanup_interrupt
ffffffff81ab3ecc T __irqentry_text_end

irqentry_text is checked by kasan, kprobes, tracing and the unwinder.

kasan uses it to filter irq stacks, i.e. to limit the stack entries to the
point where it hits something inside irqentry_text. Shouldn't be a problem
to restrict it to the actual entry code.

kprobes has a similar thing. The comment says:

	Do not optimize in the entry code due to the unstable stack
	and register handling.

The C functions are not affected by that ....

Tracing uses it to stop the printout of the function graph. Should be safe
to print the C-Code functions.

The unwinder might get confused. The comment there says:

  Don't warn if the unwinder got lost due to an interrupt in entry
  code or in the C handler before the first frame pointer got set up:

I think the unwinder one is easy to solve by having a separate section for
the C-code portion.

Thanks,

	tglx