From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753126AbcE2TIv (ORCPT ); Sun, 29 May 2016 15:08:51 -0400 Received: from mail-oi0-f45.google.com ([209.85.218.45]:35187 "EHLO mail-oi0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752839AbcE2TIu (ORCPT ); Sun, 29 May 2016 15:08:50 -0400 MIME-Version: 1.0 In-Reply-To: References: <20160525113927.GC4420@pd.tnic> From: Andy Lutomirski Date: Sun, 29 May 2016 12:08:29 -0700 Message-ID: Subject: Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it To: Borislav Petkov Cc: Brian Gerst , "linux-kernel@vger.kernel.org" , X86 ML , Kees Cook 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 May 29, 2016 11:42 AM, "Boris Petkov" wrote: > > Andy Lutomirski wrote: > >Easier said than done. struct thread_info doesn't have addr_limit on > >sensible architectures (e.g. sparc), and I'd rather not stick a bunch > >of ifdefs in generic code. > > It's not like it doesn't have an actual address limit though - I'm guessing it is something like the max userspace address on the arch... UINT_MAX or somesuch. Sure, but how do I implement that? There's no "does this arch have addr_limit in thread_info" general flag that I know of. --Andy