From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751633AbdK1F3u (ORCPT <rfc822;w@1wt.eu>);
        Tue, 28 Nov 2017 00:29:50 -0500
Received: from mail-io0-f169.google.com ([209.85.223.169]:37029 "EHLO
        mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750850AbdK1F3r (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 28 Nov 2017 00:29:47 -0500
X-Google-Smtp-Source: AGs4zMaLvvuT/krSVN4qYF3ftmM4NBrA1XiH/E3NEo1dBNHPS4o8d3PFSB8atXDPlPAhpG0uCsTtKCj67NpWno/rqQo=
MIME-Version: 1.0
In-Reply-To: <20171128042943.ebs6yzduthakxxk4@treble>
References: <20171127104529.12435-1-mingo@kernel.org> <20171127104529.12435-12-mingo@kernel.org>
 <CA+55aFyJXB4kDiX41HizJ0Bd4s+81b0eLKRcruHkjwOJ-DeM2A@mail.gmail.com> <20171128042943.ebs6yzduthakxxk4@treble>
From: Andy Lutomirski <luto@amacapital.net>
Date: Mon, 27 Nov 2017 21:29:26 -0800
Message-ID: <CALCETrXptow2p4N4zqCny-inHyEcUw4hemDnvw50i5BcKx0G6w@mail.gmail.com>
Subject: Re: [PATCH 11/21] x86/dumpstack: Handle stack overflow on all stacks
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>, Borislav Petkov <bp@alien8.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Nov 27, 2017 at 8:29 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Mon, Nov 27, 2017 at 11:26:30AM -0800, Linus Torvalds wrote:
>> On Mon, Nov 27, 2017 at 2:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> > From: Andy Lutomirski <luto@kernel.org>
>> >
>> > We currently special-case stack overflow on the task stack.  We're
>> > going to start putting special stacks in the fixmap with a custom
>> > layout, so they'll have guard pages, too.  Teach the unwinder to be
>> > able to unwind an overflow of any of the stacks.
>>
>> Why isn't this together with 01/21? The two cases seem to be entirely
>> identical and fundamentally the same issue.
>
> Yeah, they probably do belong in the same patch.
>
>> In fact, maybe the whole "stack overflow" special cases should be in
>> "get_stack_info()" itself, rather than be special-cased in the
>> callers?
>
> I would be nervous about doing that.  Several of the get_stack_info()
> callers rely on it being honest.
>
> In fact, looking deeper at the above patch, it doesn't seem convincingly
> safe to me.  What if the adjacent page doesn't exist?  Then when the
> oops dumping code dereferences the 'stack' variable, you get an oops in
> your oops.
>

Isn't the oops dumping code supposed to dereference everything using a
special safe function?

Anyway, get_stack_info() wouldn't really be lying.  It would just be
returning something where begin..end doesn't contain the requested
pointer.