[PATCH] tty/hvc_console: fix console lock ordering with spinlock

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 <redacted>
---
 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

Denis Kirjanov [off-list ref] 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.

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

On 4/4/17, Michael Ellerman [off-list ref] wrote:

Denis Kirjanov [off-list ref] writes:

quoted

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

quoted

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