printk question:why release console_sem after logbuf_lock

[buyitian]

在 2013-2-10，11:43，"Peter Teoh" <htmldeveloper at gmail.com> 写道：

> 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 <buyit at live.cn> 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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 
> 
> 
> -- 
> Regards,
> Peter Teoh
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130211/4d9fa4be/attachment.html 
-------------- next part --------------
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies