Messages in this thread | | | Date | Fri, 8 Aug 2008 10:25:00 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH 0/2] printk vs rq->lock and xtime lock |
| |
On Fri, 8 Aug 2008, Peter Zijlstra wrote: > > Sure, but the RCU callback period is at least 3 jiffies and much longer > when busy - I'm not sure how long before we force a grace period, we do > that to avoid DoS, right Paul?
I really don't think it matters. klogd is going to write the thing to _disk_ (or network), and three jiffies really don't matter. If we can fill the buffer in that kind of time, we're screwed for other reasons anyway.
> So this version would have a much higher risk of overflowing the console > buffer and making klogd miss bits. Then again, I really don't care about > klogd at _all_, I've been running with the wakeup patched out for ages.
Well, I'd care a _bit_ about klogd, but not enough to worry about a couple of jiffies. We want to wake it up at some point, but...
> Gah, the below doesn't boot - because I guess we start using rcu before > its properly set up.. should I poke at it more?
I'd certainly prefer this kind of approach. However, may I suggest:
- doing the "waitqueue_active(&log_wait)" before even bothering to do the RCU call. That, btw, will automatically mean that we wouldn't ever call the RCU code before anything is initialized.
- get rid of the "oops_in_progress" thing, since I think the whole point of that was to avoid getting the lock recursively in the first place.
- I'd worry about the "spin_lock_irqsave(&klogd_wakeup_state.lock)". What if the printk happens from call_rcu()? This is exactly what we're trying to get away from - having some parts of the kernel not able to printk() because of subtle locking issues.
For that last thing, maybe we can just make it a percpu thing and just disable irq's?
Linus
| |