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, 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.

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!

Linus


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