<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>在 2013-2-10，11:43，"Peter Teoh" <<a href="mailto:htmldeveloper@gmail.com">htmldeveloper@gmail.com</a>> 写道：<br><br></div><blockquote type="cite"><div>Details u have to look at the source code, my guess is based on the following posting:<div><br></div><div><a href="http://kerneltrap.org/mailarchive/linux-kernel/2008/1/23/595569" target="_blank">http://kerneltrap.org/mailarchive/linux-kernel/2008/1/23/595569</a></div>
<div><br></div><div><a href="https://lkml.org/lkml/2011/6/21/249" target="_blank">https://lkml.org/lkml/2011/6/21/249</a></div><div><br></div></div></blockquote><div><br></div><div>sorry, I cannot imagine why we must release <span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">console_sem after logbuf_lock.</span></div><div><span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">I need an example, thanks.</span></div><div><br></div><br><blockquote type="cite"><div><div>logic:</div><div><br></div><div>a. u want to be able to do printk from anywhere.</div>
<div>
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. </div><div>c. now problem arises when printk is happening very fast, and so this type of locks is ill-suited for printk().</div>
<div>d. later than this patch is another attempt:</div><div><br></div><div><a href="https://patchwork.kernel.org/patch/1760211/">https://patchwork.kernel.org/patch/1760211/</a></div><div><a href="https://lkml.org/lkml/2012/10/20/90">https://lkml.org/lkml/2012/10/20/90</a></div>
<div><br></div><div>where lazy irq work is being used instead.</div>
<div><br></div><div>read through the comments in the intro to the patch - it covers a lot more than i mentioned here.</div><div><br></div><div>In Documentation/lockdep_design.txt discuss about using irq tracing to trace the lock dependencies.</div>
<div><br></div><div>Lock inversion is a common computer science problem....look up wiki.</div><div><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 10:55 AM, buyitian <span dir="ltr"><<a href="mailto:buyit@live.cn" target="_blank">buyit@live.cn</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"> in the patch 0b5e1c5255e7ee8670e077e8224e5c2281229a5b, it releases console_sem after logbuf_lock, the description of this patch is as below:<br> <br>Release console_sem after unlocking the logbuf_lock so that we don't<br>
generate wakeups while holding logbuf_lock. This avoids some lock<br>inversion troubles once we remove the lockdep_off bits between<br>logbuf_lock and rq->lock (prints while holding rq->lock vs doing<br>wakeups while holding logbuf_lock).<br>
There's of course still an actual deadlock where the printk()s under<br>rq->lock will issue a wakeup from the up() call, but lockdep won't<br>warn about that since semaphores are not tracked. <br> <br> could you please give me a detail example about the issue it tries to fix? thanks.<br>
</div></div>
<br>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Peter Teoh
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Kernelnewbies mailing list</span><br><span><a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a></span><br><span><a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a></span><br></div></blockquote></body></html>