Re: [PATCH] printk: robustify printk

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 8 Aug 2008 13:57:26 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 8 Aug 2008, Andrew Morton wrote:
> > 
> > Why are we fixing this, btw?  The problem has been there forever and
> > people who hack the wakeup code could/should know about it anyway.  All
> > they need to do is to disable klogd during development.  Did the
> > problem recently become worse for some reason?
> 
> It hasn't beemn there forever at all.
> 
> Yes, there used to be reliance on the actual _scheduler_ locks. Doign a 
> wake_up() would cause runqueue locks etc to be taken.
> 
> But the xtime deadlock is fairly recent, and only happened with CFQ, I 
> think.
> 
> And _that_ is the irritating one. I personally wouldn't mind at all if 
> there is some printk() dependency on the core runqueue rq->lock or on the 
> RCU locking thing. But look at xtime_lock. THAT is a disaster.
> 
> Just grep for it. 
> 
> 

<actually reads stuff>

Yes, not being able to do printk inside xtime_lock would be a disaster.
We decided that about 1.5 years ago last time we added then fixed this
bug (at the time I think I identified multiple already-present printks
inside xtime_lock, on error paths).  Did we go and re-add this bug recently
or did we just never fix it?   Doesn't matter, I guess.

> So I personally actually like the RCU version best. Yes, it still depends 
> on really core locking. But it's really core and low-level and _confined_ 
> locking, where a comment in a single place would probably suffice. Compare 
> that to all the places where we take the xtime_lock for writing!

Sure, the cant-printk-in-rcupreempt.c limitation should be quite
acceptable.