Messages in this thread | | | Date | Fri, 8 Aug 2008 14:13:40 -0700 | From | Andrew Morton <> | Subject | Re: [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.
| |