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 S1759703AbcIMSaD (ORCPT <rfc822;w@1wt.eu>);
        Tue, 13 Sep 2016 14:30:03 -0400
Received: from mail-wm0-f65.google.com ([74.125.82.65]:34870 "EHLO
        mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754638AbcIMSaC (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 13 Sep 2016 14:30:02 -0400
Date: Tue, 13 Sep 2016 20:29:57 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H . Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, Andy Lutomirski <luto@amacapital.net>,
        Steven Rostedt <rostedt@goodmis.org>, Brian Gerst <brgerst@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Byungchul Park <byungchul.park@lge.com>,
        Nilay Vaish <nilayvaish@gmail.com>
Subject: Re: [PATCH v2] x86/dumpstack: allow preemption in
 show_stack_log_lvl() and dump_trace()
Message-ID: <20160913182957.GA25373@gmail.com>
References: <20160908214748.vywksxm2jycre66o@treble>
 <a0ca0b1044eca97d4f0ec7c1619cf80b3b65560d.1473371307.git.jpoimboe@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a0ca0b1044eca97d4f0ec7c1619cf80b3b65560d.1473371307.git.jpoimboe@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> show_stack_log_lvl() and dump_trace() are already preemption safe:
> 
> - If they're running in irq or exception context, preemption is already
>   disabled and the percpu stack pointers can be trusted.
> 
> - If they're running with preemption enabled, they must be running on
>   the task stack anyway, so it doesn't matter if they're comparing the
>   stack pointer against a percpu stack pointer from this CPU or another
>   one: either way it won't match.

Yeah, so I'm having second thoughts about this patch. My worry here is: what if we 
get preempted in this sequence?

If the kernel is borked real bad then we could get technically correct but really, 
really weird looking stack traces if for example the task stack is getting 
corrupted or something like that.

Dunno. How long does the worst-case processing here take on a typical x86 system, 
does it really matter to scheduling latency?

Thanks,

	Ingo