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 S1751831AbdBAPjP (ORCPT <rfc822;w@1wt.eu>);
        Wed, 1 Feb 2017 10:39:15 -0500
Received: from mx2.suse.de ([195.135.220.15]:39666 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751287AbdBAPjO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 1 Feb 2017 10:39:14 -0500
Date: Wed, 1 Feb 2017 16:39:10 +0100
From: Petr Mladek <pmladek@suse.com>
To: Peter Zijlstra <peterz@infradead.org>
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: <20170201153910.GL6620@pathway.suse.cz>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170201093739.GT6515@twins.programming.kicks-ass.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed 2017-02-01 10:37:39, Peter Zijlstra wrote:
> On Wed, Feb 01, 2017 at 10:06:25AM +0100, Jan Kara wrote:
> > Clearly scheduler code (update_load_avg) calls WARN_ON from scheduler while
> > holding rq_lock which has been always forbidden. Sergey and Petr were doing
> > some work to prevent similar deadlocks but I'm not sure how far they
> > went...
> 
> Its not forbidden, just can result in the occasional deadlock, meh.
> 
> 
> In any case, there's a patch in tip fixing that warn trigger.

I guess that you are talking about the introduction of
#define SCHED_WARN_ON(x)	WARN_ONCE(x, #x)

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

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);			\
})


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);				\
})

Best Regards,
Petr