Denis Kirjanov <k...@linux-powerpc.org> writes: > hvc_remove() takes a spin lock first then acquires the console > semaphore. This situation can easily lead to a deadlock scenario > where we call scheduler with spin lock held.
Have you actually hit the deadlock? Because that code's been like that for years and I've never received a bug report. > diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c > index b19ae36..a8d3991 100644 > --- a/drivers/tty/hvc/hvc_console.c > +++ b/drivers/tty/hvc/hvc_console.c > @@ -920,17 +920,17 @@ int hvc_remove(struct hvc_struct *hp) > > tty = tty_port_tty_get(&hp->port); > > + console_lock(); > spin_lock_irqsave(&hp->lock, flags); > if (hp->index < MAX_NR_HVC_CONSOLES) { > - console_lock(); > vtermnos[hp->index] = -1; > cons_ops[hp->index] = NULL; > - console_unlock(); > } > > /* Don't whack hp->irq because tty_hangup() will need to free the irq. > */ > > spin_unlock_irqrestore(&hp->lock, flags); > + console_unlock(); I get that you're trying to do the minimal change, but I don't think the result is ideal. If this isn't a console hvc then we take both locks but do nothing. So what about: if (hp->index < MAX_NR_HVC_CONSOLES) { console_lock(); spin_lock_irqsave(&hp->lock, flags); vtermnos[hp->index] = -1; cons_ops[hp->index] = NULL; spin_unlock_irqrestore(&hp->lock, flags); console_unlock(); } cheers