Messages in this thread | | | Date | Sat, 1 Jul 2000 18:31:12 -0700 (PDT) | From | Chris Lattner <> | Subject | [PATCH #2] console lock grabbed too early in printk... |
| |
Okay, try two. :)
I don't think that completely redesigning the console before 2.4 goes out is such a good idea... so here is a much smaller fix that also happens to fix my previous oversight (yeeeouch! :).
Basically, printk needs to be locked more finely... there is no reason in the world for the console lock to protect "buf" in addition to all the console stuff... 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.
This should reduce some console latency by making the console lock unheld for the vsprintf but held for the real console stuff... This patch keeps the common case nearly identical in performance: it only does a kmalloc during the extremely unlikely cases that are not handled now... [okay, I guess deadlock is "handling" it... but... :]
Personally, I didn't like the idea of having one "buf" per proc, because it doesn't fix the recursion problem, it expands the needed data space (albeit not by much), and (if that approach were to be allied more generally) would bloat the kernel by a lot. The one thing it had going for it was the fact that you could be vsprintf'ing in parrellel! :)
Anyways, let me know if I did something stupid again. :)
-Chris
- 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/
| |