Messages in this thread | | | From | Keith Owens <> | Subject | Re: [PATCH #2] console lock grabbed too early in printk... | Date | Sun, 02 Jul 2000 18:33:37 +1000 |
| |
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/
| |