Whoa there... this buffer isn't allocated by just ANY thread that has
contention on the lock... it's only allocated if the thread that OWNS the
lock reenters printk... so in all cases that don't cause deadlock now,
behavior is identical...
Is there a kmalloc flag that you can pass that says not to sleep? I'm not
too familiar with that area...
Thanks,
-Chris
On Sun, 2 Jul 2000, Keith Owens wrote:
> On Sat, 1 Jul 2000 18:31:12 -0700 (PDT),
> Chris Lattner <sabre@skylab.org> wrote:
> >... so this patch adds protection to buf, moves buf into
> >printk (as a static array), AND allows _SAFE_ recursion by kmalloc'ing a
> >new buffer if "buf" is in use.
>
> kmalloc(,GFP_KERNEL) in printk is not safe. Lots of code that calls
> printk is not allowed to sleep which means that printk is never allowed
> to sleep - kmalloc(,GFP_KERNEL) can sleep. Also kmalloc can call back
> to printk, unlikely but a possible source of a runaway loop which will
> blow the kernel stack.
>
> Instead of allocating another buffer, just count how many times you
> failed because the lock was in use. The code that owns the buffer can
> issue the original message then check if the lost message counter has
> changed and issue a message "BUG: <n> printk messages lost". Far safer
> than calling other kernel services.
>
-
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