* [PATCH] tty/hvc_console: fix console lock ordering with spinlock
@ 2017-03-30 14:06 Denis Kirjanov
[not found] ` <877f30v19q.fsf@concordia.ellerman.id.au>
0 siblings, 1 reply; 2+ messages in thread
From: Denis Kirjanov @ 2017-03-30 14:06 UTC (permalink / raw)
To: gregkh, jslaby; +Cc: linuxppc-dev, linux-kernel, benh, Denis Kirjanov
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.
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
---
drivers/tty/hvc/hvc_console.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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();
/*
* We 'put' the instance that was grabbed when the kref instance
--
1.8.3.1
^ permalink raw reply [flat|nested] 2+ messages in thread[parent not found: <877f30v19q.fsf@concordia.ellerman.id.au>]
* Re: [PATCH] tty/hvc_console: fix console lock ordering with spinlock [not found] ` <877f30v19q.fsf@concordia.ellerman.id.au> @ 2017-04-04 12:54 ` Denis Kirjanov 0 siblings, 0 replies; 2+ messages in thread From: Denis Kirjanov @ 2017-04-04 12:54 UTC (permalink / raw) To: Michael Ellerman; +Cc: gregkh, jslaby, linuxppc-dev, linux-kernel, benh On 4/4/17, Michael Ellerman <mpe@ellerman.id.au> wrote: > Denis Kirjanov <kda@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. Nope, I didn't. I've found the bug in the code while looking at the lockdep output > >> 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(); > } Are you sure that we don't corrupt the hp->index between hvc_poll in interrupt context and hvc_remoev? > > cheers > ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-04-04 12:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-30 14:06 [PATCH] tty/hvc_console: fix console lock ordering with spinlock Denis Kirjanov
[not found] ` <877f30v19q.fsf@concordia.ellerman.id.au>
2017-04-04 12:54 ` Denis Kirjanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®