linux-kernel - Re: [PATCHv7 6/8] printk: use printk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170201153910.GL6620@pathway.suse.cz>
Date:   Wed, 1 Feb 2017 16:39:10 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Jan Kara <jack@...e.cz>, Ross Zwisler <zwisler@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Tejun Heo <tj@...nel.org>, Calvin Owens <calvinowens@...com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Hurley <peter@...leysoftware.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk

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