From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752020AbdK0IPM (ORCPT ); Mon, 27 Nov 2017 03:15:12 -0500 Received: from merlin.infradead.org ([205.233.59.134]:47814 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbdK0IPJ (ORCPT ); Mon, 27 Nov 2017 03:15:09 -0500 Date: Mon, 27 Nov 2017 09:14:48 +0100 From: Peter Zijlstra To: Thomas Gleixner Cc: Ingo Molnar , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , LKML , Andy Lutomirski , "H . Peter Anvin" , 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 Message-ID: <20171127081448.27wy6jq2dexa7em5@hirez.programming.kicks-ass.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 25, 2017 at 05:08:08PM +0100, Thomas Gleixner wrote: > 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 I'm confused though; for IDT we have that trampoline Andy did. So the interrupt should land on the entry stack, do the switch magic and then call the 'real' IDT entry, no? So why do these functions need to be mapped at all?