Re: [PATCH #2] console lock grabbed too early in printk...

From: Andrew Morton (andrewm@uow.edu.au)
Date: Sun Jul 02 2000 - 03:40:56 EST


Chris Lattner wrote:
> ...
>
> Wait, back up, let me get this straight. There are two situations here:

Chris,

you're right. printk() can deadlock. Bear in mind that any
deadlock-detector for printk() needs to be aware of which CPU holds the
spinlock. That is, a simple

printk()
{
        if (!spin_trylock(&console_lock))
                do_something_strange()

}

is wrong.

You should only take avoiding action if the lock is held by this_cpu.
This implies that in all places where the console lock is taken you'll
need to record which CPU holds it. Not too hard. Alternatively, just
put an upper bound on the spin duration (one second would suffice).

You have a choice of three actions when the deadlock situation is
detected:

1: Return without printing

  I think this is bad. You're almost certainly throwing
  away a vital piece of information.

2: Save the message somewhere and print it out later.

  This is hard. Probably the safest approach is to create
  a 'static char backup_buf[1024]' and use that instead,
  poll it later.

3: Bust the spinlock and make the current printk() come out.

  I think this is the best approach, but it's tricky to
  get right. Perhaps you should BUG() immediately after
  doing the output.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:10 EST