logic:
a. u want to be able to do printk from anywhere.
b. but every call to printk requires a console_sem lock to be acquired. after acquiring console_sem, printk actually serializes the output to a memory buffer.
c. now problem arises when printk is happening very fast, and so this type of locks is ill-suited for printk().
d. later than this patch is another attempt:
where lazy irq work is being used instead.
read through the comments in the intro to the patch - it covers a lot more than i mentioned here.
In Documentation/lockdep_design.txt discuss about using irq tracing to trace the lock dependencies.
Lock inversion is a common computer science problem....look up wiki.
On Sat, Feb 9, 2013 at 10:55 AM, buyitian <buyit@xxxxxxx> wrote:
in the patch 0b5e1c5255e7ee8670e077e8224e5c2281229a5b, it releases console_sem after logbuf_lock, the description of this patch is as below:
Release console_sem after unlocking the logbuf_lock so that we don't
generate wakeups while holding logbuf_lock. This avoids some lock
inversion troubles once we remove the lockdep_off bits between
logbuf_lock and rq->lock (prints while holding rq->lock vs doing
wakeups while holding logbuf_lock).
There's of course still an actual deadlock where the printk()s under
rq->lock will issue a wakeup from the up() call, but lockdep won't
warn about that since semaphores are not tracked.
could you please give me a detail example about the issue it tries to fix? thanks.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Regards,
Peter Teoh
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
