lkml.org 
[lkml]   [2008]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] printk: robustify printk
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.


\
 
 \ /
  Last update: 2008-08-08 23:17    [W:0.067 / U:1.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site