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 S932298AbbFWI4h (ORCPT <rfc822;w@1wt.eu>);
	Tue, 23 Jun 2015 04:56:37 -0400
Received: from mail-wg0-f42.google.com ([74.125.82.42]:34897 "EHLO
	mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932093AbbFWI4a (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 23 Jun 2015 04:56:30 -0400
Date: Tue, 23 Jun 2015 10:56:24 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>, Kees Cook <keescook@chromium.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Denys Vlasenko <vda.linux@googlemail.com>,
        Brian Gerst <brgerst@gmail.com>,
        =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker <fweisbec@gmail.com>,
        X86 ML <x86@kernel.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v2 03/14] notifiers: Assert that RCU is watching in
 notify_die
Message-ID: <20150623085624.GA2882@gmail.com>
References: <cover.1434654252.git.luto@kernel.org>
 <c9b5f7d2525e17192a983a31f2f0d8eeec6c4c74.1434654252.git.luto@kernel.org>
 <20150622113649.GB20244@pd.tnic>
 <CALCETrXaGBs_1j_fv894h=xrfdBLt57MM9i+YH_PDR3GDteoQQ@mail.gmail.com>
 <20150622163333.GC20244@pd.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150622163333.GC20244@pd.tnic>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Borislav Petkov <bp@alien8.de> wrote:

> On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote:
>
> > notify_die is misnamed and has little to do with death. It's really just 
> > notifying about an exception, and we might end up oopsing, sending a signal, 
> > or neither.
> 
> But if we oops and wedge solid afterwards, it might happen that only the first 
> splat comes out on the console, no? And that will be the lockdep splat which 
> would be useless for debugging the actual problem...

So I think the theory is that crashes do happen, and that any RCU warning only 
matters to (usually) small race windows.

So by the time a difficult crash truly happens, exactly in that race window, we'd 
have fixed the RCU warning long ago.

I.e. the placement of the RCU warning isn't really relevant in the long run, as it 
should not trigger.

In the short run it's probably more important to have it first, because if we have 
that RCU race then we don't know whether we can trust anything that happens after 
executing the (flawed) notifier chain.

Does that logic make sense to you?

Thanks,

	Ingo