From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751882AbdKYQIS (ORCPT ); Sat, 25 Nov 2017 11:08:18 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:49974 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751231AbdKYQIR (ORCPT ); Sat, 25 Nov 2017 11:08:17 -0500 Date: Sat, 25 Nov 2017 17:08:08 +0100 (CET) From: Thomas Gleixner To: Ingo Molnar cc: Andy Lutomirski , Dave Hansen , Josh Poimboeuf , LKML , Andy Lutomirski , "H . Peter Anvin" , Peter Zijlstra , Borislav Petkov , Linus Torvalds , Steven Rostedt , Andrey Ryabinin , kasan-dev@googlegroups.com, Masami Hiramatsu Subject: Re: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping In-Reply-To: <20171125111721.p2o3khstk5tawzqt@gmail.com> Message-ID: References: <20171124172411.19476-1-mingo@kernel.org> <20171124202237.oytdkqq25s3ak2ul@gmail.com> <20171124220934.q7ovq4yzaihevqls@gmail.com> <464B14E7-EC38-4A5A-8BF6-B086F437C6D1@amacapital.net> <20171124225311.zpbgsejobpzxm7tb@gmail.com> <20171125092113.p2shs3hjy6q2mip2@gmail.com> <20171125093243.4gmkelmyb4mnhvos@gmail.com> <20171125093949.qbnibvj3nej5vidz@gmail.com> <20171125111721.p2o3khstk5tawzqt@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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