From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752870AbcE2Qof (ORCPT ); Sun, 29 May 2016 12:44:35 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:34117 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752750AbcE2Qoe (ORCPT ); Sun, 29 May 2016 12:44:34 -0400 MIME-Version: 1.0 In-Reply-To: <20160525113240.GB4420@pd.tnic> References: <20160525113240.GB4420@pd.tnic> From: Andy Lutomirski Date: Sun, 29 May 2016 09:44:13 -0700 Message-ID: Subject: Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it To: Borislav Petkov Cc: Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Kees Cook , Brian Gerst Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 25, 2016 at 4:32 AM, Borislav Petkov wrote: > On Tue, May 24, 2016 at 03:48:41PM -0700, Andy Lutomirski wrote: >> This will help debug OOPSes related to USER_DS vs KERNEL_DS. >> >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/kernel/dumpstack_32.c | 4 ++++ >> arch/x86/kernel/dumpstack_64.c | 5 +++++ >> 2 files changed, 9 insertions(+) >> >> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c >> index 464ffd69b92e..5dbb08fd8291 100644 >> --- a/arch/x86/kernel/dumpstack_32.c >> +++ b/arch/x86/kernel/dumpstack_32.c >> @@ -124,8 +124,12 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs, >> void show_regs(struct pt_regs *regs) >> { >> int i; >> + struct thread_info *ti = current_thread_info(); >> >> show_regs_print_info(KERN_EMERG); >> + if (ti->addr_limit.seg != TASK_SIZE_MAX) >> + printk(KERN_DEFAULT "task.addr_limit: 0x%lx\n", >> + ti->addr_limit.seg); > > I guess we can dump that unconditionally just to be consistent and so > that all oopses look the same, i.e., with that line always present. > I thought about doing that, but I always hate when things scroll off the screen, and 99% of the time the addr_limit will be TASK_SIZE_MAX and the line won't be interesting. --Andy