From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751413AbdKYLR1 (ORCPT ); Sat, 25 Nov 2017 06:17:27 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:42156 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbdKYLR0 (ORCPT ); Sat, 25 Nov 2017 06:17:26 -0500 X-Google-Smtp-Source: AGs4zMYNnM7olUxSEwQg08FP91Dk4lqMcfIkQGga3D/dw5FurCQKZeFI5ojKKprM2BA0jlZ5prxHhA== Date: Sat, 25 Nov 2017 12:17:21 +0100 From: Ingo Molnar To: Andy Lutomirski , Dave Hansen , Josh Poimboeuf Cc: linux-kernel@vger.kernel.org, Andy Lutomirski , Thomas Gleixner , "H . Peter Anvin" , Peter Zijlstra , Borislav Petkov , Linus Torvalds Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping Message-ID: <20171125111721.p2o3khstk5tawzqt@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171125093949.qbnibvj3nej5vidz@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Ingo Molnar 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 =============> >>From 19bbacd5f7c66b4716716bad97848a9cacd6fe68 Mon Sep 17 00:00:00 2001 From: Ingo Molnar Date: Sat, 25 Nov 2017 12:10:38 +0100 Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping Backmerge to: f9e7e52fa076: x86/mm/kaiser: Unmap kernel from userspace page tables (core patch) Signed-off-by: Ingo Molnar --- arch/x86/mm/kaiser.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c index 1eb27b410556..ea8887bf550a 100644 --- a/arch/x86/mm/kaiser.c +++ b/arch/x86/mm/kaiser.c @@ -412,6 +412,8 @@ void __init kaiser_init(void) 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 fixed map address of the idt_table */ kaiser_add_user_map_early((void *)idt_descr.address,