David Howells <[EMAIL PROTECTED]> wrote:
>
> The attached patch prevents oopses interleaving with characters from other
> printks on other machines by only zapping the locks if the oops is happening
> on the machine holding the lock.
(s/machine/CPU/)
hm, I guess it adds a theoretical deadlock if some other CPU is in the
middle of printk and is trying to take some_lock and this CPU takes an oops
while holding some_lock. Probably that's an acceptable tradeoff though.
> --- linux-2.6.12-mm1/kernel/printk.c 2005-06-22 13:54:08.000000000 +0100
> +++ linux-2.6.12-mm1-cachefs-wander/kernel/printk.c 2005-06-22
> 13:57:02.000000000 +0100
> @@ -514,6 +514,9 @@ asmlinkage int printk(const char *fmt, .
> return r;
> }
>
> +/* cpu currently holding logbuf_lock */
> +static volatile int printk_cpu = -1;
> +
Does this guy really need to be volatile? Coud we use atomic_t and lose
that wmb()?
> asmlinkage int vprintk(const char *fmt, va_list args)
> {
> unsigned long flags;
> @@ -522,11 +525,15 @@ asmlinkage int vprintk(const char *fmt,
> static char printk_buf[1024];
> static int log_level_unknown = 1;
>
> - if (unlikely(oops_in_progress))
> + if (unlikely(oops_in_progress) && printk_cpu == smp_processor_id())
> + /* If a crash is occurring during printk() on this CPU,
> + * make sure we can't deadlock */
Methinks this should be raw_smp_processor_id().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
