On Fri 2017-01-13 11:52:55, Sergey Senozhatsky wrote:
> On (01/12/17 14:10), Petr Mladek wrote:
> [..]
> > > /**
> > > * console_lock - lock the console system for exclusive use.
> > > *
> > > @@ -2316,7 +2321,7 @@ EXPORT_SYMBOL(console_unlock);
> > > */
> > > void __sched console_conditional_schedule(void)
> > > {
> > > - if (console_may_schedule)
> > > + if (get_console_may_schedule())
> >
> > Note that console_may_schedule should be zero when
> > the console drivers are called. See the following lines in
> > console_unlock():
> >
> > /*
> > * Console drivers are called under logbuf_lock, so
> > * @console_may_schedule should be cleared before; however, we may
> > * end up dumping a lot of lines, for example, if called from
> > * console registration path, and should invoke cond_resched()
> > * between lines if allowable. Not doing so can cause a very long
> > * scheduling stall on a slow console leading to RCU stall and
> > * softlockup warnings which exacerbate the issue with more
> > * messages practically incapacitating the system.
> > */
> > do_cond_resched = console_may_schedule;
> > console_may_schedule = 0;
>
>
>
> console drivers are never-ever-ever getting called under logbuf lock.
> never. with disabled local IRQs - yes. under logbuf lock - no. that
> would soft lockup systems in really bad ways, otherwise.
Sure. It is just a misleading comment that someone wrote. I have
already fixed this in my patch.
> the reason why we set console_may_schedule to zero in
> console_unlock() is.... VT. and lf() function in particular.
>
> commit 78944e549d36673eb6265a2411574e79c28e23dc
> Author: Antonino A. Daplas XXXX
> Date: Sat Aug 5 12:14:16 2006 -0700
>
> [PATCH] vt: printk: Fix framebuffer console triggering might_sleep
> assertion
>
> Reported by: Dave Jones
>
> Whilst printk'ing to both console and serial console, I got this...
> (2.6.18rc1)
>
> BUG: sleeping function called from invalid context at kernel/sched.c:4438
> in_atomic():0, irqs_disabled():1
This is basically the same problem that Testuo has. This commit added
the line
console_may_schedule = 0;
Tetsuo found that we did not clear it when going back
via the "again:" goto target.
> and we really don't want to cond_resched() when we are in panic.
> that's why console_flush_on_panic() sets it to zero explicitly.
This actually works even with the bug. console_flush_on_panic()
is called with interrupts disabled in panic(). Therefore
console_trylock would disable cond_resched.
Best Regards,
Petr
