Re: [PATCH 0/2] printk vs rq->lock and xtime lock

[Linus Torvalds <torvalds@linux-foundation.org>]

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