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 S1752583AbdBAQP6 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Feb 2017 11:15:58 -0500
Received: from bombadil.infradead.org ([65.50.211.133]:51766 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751096AbdBAQP5 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Feb 2017 11:15:57 -0500
Date: Wed, 1 Feb 2017 17:15:41 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Jan Kara <jack@suse.cz>, Ross Zwisler <zwisler@gmail.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Tejun Heo <tj@kernel.org>, Calvin Owens <calvinowens@fb.com>,
        Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Hurley <peter@hurleysoftware.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Subject: Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk
Message-ID: <20170201161541.GU6515@twins.programming.kicks-ass.net>
References: <20161227141611.940-1-sergey.senozhatsky@gmail.com>
 <20161227141611.940-7-sergey.senozhatsky@gmail.com>
 <CAOxpaSWz_mJNQFj1NCfmaZU_tzAw34SN9CfH+55o8J+WEkcmxA@mail.gmail.com>
 <20170201090625.GC11567@quack2.suse.cz>
 <20170201093739.GT6515@twins.programming.kicks-ass.net>
 <20170201153910.GL6620@pathway.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170201153910.GL6620@pathway.suse.cz>
User-Agent: Mutt/1.5.23.1 (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

On Wed, Feb 01, 2017 at 04:39:10PM +0100, Petr Mladek wrote:
> I guess that you are talking about the introduction of
> #define SCHED_WARN_ON(x)	WARN_ONCE(x, #x)

No, there's a lot of regular WARN/WARN_ON/etc.. usage in the scheduler.
That thing was just a convenience wapper to print the condition that
warned.

> It reduces the risk of the deadlock but some risk is still there.
> IMHO, it does not avoid the lockdep warning.

It doesn't reduce anything, nor did it ever try. I really don't care if
it occasionally deadlocks, as long as it mostly gets out.

> One solution would be to hide the occasional deadlock and disable
> lockdep in SCHED_WARN_ON():
> 
> #define SCHED_WARN_ON(x)				\
> ({							\
> 	int __ret_sched_warn_on;			\
> 	lockdep_off();					\
> 	__ret_sched_warn_on = WARN_ONCE(x, #x);		\
> 	lockdep_on();					\
> 	unlikely(__ret_sched_warn_on);			\
> })

Like said, there's plenty of regular WARN/WARN_ON usage, so this will
not help much.

> Another solution would be to redirect it into the
> alternative buffer and let it printed later:
> 
> #define SCHED_WARN_ON(x)	WARN_ONCE(x, #x)		\
> ({								\
> 	unsigned long __sched_warn_on_flags;			\
> 	printk_safe_enter_irqsave(__sched_warn_on_flags);	\
> 	__ret_sched_warn_on = WARN_ONCE(x, #x);			\
> 	printk_safe_exit_irqrestore(__sched_warn_on_flags);	\
> 	unlikely(__ret_sched_warn_on);				\
> })

So my kernel doesn't yet have that abomination; that redirects it to a
buffer for later printing right? I hope that buffer is big enough to
hold a full WARN splat and the machine lives long enough to make it to
printing that crap.