Re: Regression in next with use printk_safe buffers in printk

[Sergey Senozhatsky]

On (02/14/17 17:18), Peter Zijlstra wrote:
> On Wed, Feb 15, 2017 at 01:01:40AM +0900, Sergey Senozhatsky wrote:
> > 
> > but I'm a bit confused by rt_b->rt_runtime_lock in this unsafe lock
> > scenario (so it's not ABBA, but ABAD)
> > 
> > >   lock(hrtimer_bases.lock);
> > >                                lock(&rt_b->rt_runtime_lock);
> > >                                lock(hrtimer_bases.lock);
> > >   lock(tk_core);
> > >
> > >
> > > Chain exists of:
> > >
> > >	tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock
> > 
> > 
> > I'm lacking some knowledge here, sorry. where does the tk_core --> &rt_b->rt_runtime_lock
> > come from?
> 
> rt_b->rt_runtime_lock is one of the scheduler locks, since we do
> printk() under tk_core, which does semaphore muck, which then includes
> the entire scheduler chain of locks.

thanks, Peter.

that crossed my mind, but I kinda assumed that we do printk() from
under tk_core using sched fair, and rt_runtime_lock is from sched rt.


so something like below, perhaps. would be helpful if Tony can test it.

(I'll send out this patch 'in a proper way' tomorrow, after some sleep,
it's 2am here).

8< ====