[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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. :)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.274 / U:0.432 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site