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.