Messages in this thread | | | Date | Wed, 3 Feb 2016 09:04:47 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH v2] lock/semaphore: Avoid an unnecessary deadlock within up() |
| |
* Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> On (02/03/16 08:28), Ingo Molnar wrote: > [..] > > So why not move printk away from semaphores? Semaphores are classical constructs > > that have legacies and are somewhat non-obvious to use, compared to modern, > > simpler locking primitives. I'd not touch their implementation, unless we are > > absolutely sure this is a safe optimization. > > semaphore's spin_lock is not the only spin lock that printk acquires. it also > takes the logbuf_lock (and different locks in console drivers (up to console > driver)). > > Jan Kara posted a patch that offloads printing job > (console_trylock()-console_unlock()) from printk() call (when printk can offload > it). so semaphore and console driver's locks will go away (mostly) with Jan's > patch. logbug spin_lock, however, will stay.
Well, but this patch of yours only affects the semaphore code, so it does not change the logbuf_lock situation.
Furthermore, logbuf_lock already has recursion protection:
/* * Ouch, printk recursed into itself! */ if (unlikely(logbuf_cpu == this_cpu)) {
so it should not be possible to re-enter the printk() logbuf_lock critical section from the spinlock code. (There are other ways to get the logbuf_lock - if those are still triggerable then they should be fixed.)
In any case, recursion protection is generally done in the debugging facilities trying to behave lockless.
Thanks,
Ingo
| |