在 2013-2-10，11:43，"Peter Teoh" <[email protected]> 写道：
> Details u have to look at the source code, my guess is based on the following > posting: > > http://kerneltrap.org/mailarchive/linux-kernel/2008/1/23/595569 > > https://lkml.org/lkml/2011/6/21/249 > sorry, I cannot imagine why we must release console_sem after logbuf_lock. I need an example, thanks. > 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: > > https://patchwork.kernel.org/patch/1760211/ > https://lkml.org/lkml/2012/10/20/90 > > 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 <[email protected]> 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 >> [email protected] >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > Regards, > Peter Teoh > _______________________________________________ > Kernelnewbies mailing list > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
