Messages in this thread | | | Date | Mon, 8 Feb 2010 14:06:48 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/2] printk delay for each line break instead of callback |
| |
On Sat, 6 Feb 2010 21:34:25 +0800 Dave Young <hidave.darkstar@gmail.com> wrote:
> printk delay for every callback does not make sense, change to delay every line > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com> > --- > > kernel/printk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2.6.orig/kernel/printk.c 2010-02-02 13:38:47.646659531 +0800 > +++ linux-2.6/kernel/printk.c 2010-02-02 13:39:19.446657319 +0800 > @@ -678,7 +678,6 @@ asmlinkage int vprintk(const char *fmt, > char *p; > > boot_delay_msec(); > - printk_delay(); > > preempt_disable(); > /* This stops the holder of console_sem just where we want him */ > @@ -746,6 +745,7 @@ asmlinkage int vprintk(const char *fmt, > */ > for ( ; *p; p++) { > if (new_text_line) { > + printk_delay(); > /* Always output the token */ > emit_log_char('<'); > emit_log_char(current_log_level + '0');
This moves the printk_delay() so that it is now inside spin_lock_irqsave(logbuf_lock).
This fixes the race I mentioned in the previous email, but it seems a bad idea. If the delay is long enough, it could even cause other CPUs to get hit by the NMI watchdog when trying to acquire logbuf_lock.
A better approach would be to perform the calculation of "how long must I delay" at this site, but perform the actual delay later, after the raw_local_irq_restore(). This means that if the printk contains "a\nb\nc\n" then we won't delay until the final \n, but that seems a fairly small problem.
| |