lkml.org 
[lkml]   [2017]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv7 6/8] printk: use printk_safe buffers in printk
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.

\
 
 \ /
  Last update: 2017-02-01 17:16    [W:0.236 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site