Let's first figure out if it works.
I would still like to try applying your patches that went into printk.git, but for now I wonder if we can get Steven's patch into 4.14 first, for at least we know it mitigated the issue if not fundamentally addressed it, and we've agreed it's an innocuous change that doesn't risk breaking stable.
I haven't done this before so I'll need your help. What's the next step to actually get Steven's patch *in* linux-4.14.y? According to https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html I am supposed to send an email with the patch ID and subject, which are both mentioned in this email. Should I send another one? What's the process like? Thanks!
On Thu, Nov 8, 2018 at 10:47 PM Sergey Senozhatsky sergey.senozhatsky.work@gmail.com wrote:
On (11/01/18 09:05), Daniel Wang wrote:
Another deadlock scenario could be the following one:
printk() console_trylock() down_trylock() raw_spin_lock_irqsave(&sem->lock, flags) <NMI> panic() console_flush_on_panic() console_trylock() raw_spin_lock_irqsave(&sem->lock, flags) // deadlockThere are no patches addressing this one at the moment. And it's unclear if you are hitting this scenario.
I am not sure, but Steven's patches did make the deadlock I saw go away...
You certainly can find cases when "busy spin on console_sem owner" logic can reduce some possibilities.
But spin_lock(&lock); NMI; spin_lock(&lock); code is still in the kernel.
A little swamped by other things lately but I'll run a test with it. If it works, would you recommend taking your patch alone
Let's first figure out if it works.
-ss
-- Best, Daniel
On Thu, Nov 8, 2018 at 10:47 PM Sergey Senozhatsky sergey.senozhatsky.work@gmail.com wrote:
On (11/01/18 09:05), Daniel Wang wrote:
Another deadlock scenario could be the following one:
printk() console_trylock() down_trylock() raw_spin_lock_irqsave(&sem->lock, flags) <NMI> panic() console_flush_on_panic() console_trylock() raw_spin_lock_irqsave(&sem->lock, flags) // deadlockThere are no patches addressing this one at the moment. And it's unclear if you are hitting this scenario.
I am not sure, but Steven's patches did make the deadlock I saw go away...
You certainly can find cases when "busy spin on console_sem owner" logic can reduce some possibilities.
But spin_lock(&lock); NMI; spin_lock(&lock); code is still in the kernel.
A little swamped by other things lately but I'll run a test with it. If it works, would you recommend taking your patch alone
Let's first figure out if it works.
-ss