On Sun, 2 Jul 2000 01:03:00 -0700 (PDT),
Chris Lattner <sabre@skylab.org> wrote:
>> I think you are missing the point. printk can be called even before
>> kmalloc is usable and you cannot tell if kmalloc can be called yet.
>> Yes, it is unlikely but crashing during debugging just complicates
>> things. Far better to just count and report dropped messages and never
>> call any other kernel functions from printk. It also keeps a critical
>> kernel function nice and simple.
>
>Wait, back up, let me get this straight. There are two situations here:
>
>1. Recursive printk occurs before kmalloc is initialized:
>You claim that a panic is WORSE for debugging that an undetected deadlock
>is? How does that assist with debugging???
The deadlock shows up in printk where the problem is obvious. A call
to kmalloc before it is ready will break somewhere else in kernel, well
away from the real problem and harder to debug. I have absolutely no
objection to removing the deadlock, but calling extra functions from
printk is wrong.
>2. Recursive printk occurs after kmalloc is initialized:
>You claim that merely counting the failed messages is better than doing
>_THE_RIGHT_THING_ is every case except OOM (which would be treated quite
>similarly to what you are describing....
If kmalloc ever calls back to printk then you get recursion and blow
the kernel stack, again confusing the original problem. There are
calls from kmalloc code back to printk, these are mainly for error
conditions but what if somebody wants to debug kmalloc with extra
printk statements? In the past it was safe because printk never called
anything else, but your patch introduces recursion. Any kernel
functions called from printk can introduce an extra source of errors.
>btw, if nothing else, why not just print out the format str on OOM? That
>way you don't even need a buffer...
Possible, except that one of the things that the console lock does is
stop multiple cpus writing to the console at the same time. Bypass the
console lock to do output and you get overlapping text under SMP - hard
to read.
-
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