linux-kernel - [PATCH -rt] airo: threaded IRQ handler sleeps forever

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <45ED7D6B.7010404@redhat.com>
Date:	Tue, 06 Mar 2007 15:40:43 +0100
From:	Michal Schmidt <mschmidt@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dan Williams <dcbw@...hat.com>
Subject: [PATCH -rt] airo: threaded IRQ handler sleeps forever

The airo driver tries to avoid excessive latencies when issuing commands
to the card by calling schedule() after several retries. But
issuecommand() can be run from an interrupt handler. The function is
careful enough to check with in_atomic() if it is safe to call schedule().
This check breaks when the interrupt handler is threaded, because then
in_atomic() is always false there. The handler is run as
TASK_INTERRUPTIBLE, so schedule() takes it off the runqueue and it never
wakes up again.
Here's an obvious fix - simply don't call schedule() when using
preemptible hardirqs.
An improved solution might be to identify the commands that take so long
to issue and avoid sending them from the interrupt handler. In my
testing there was only one such command: CMD_ACCESS. I need to
investigate if it's always possible to delay it to airo's kthread.

Signed-off-by: Michal Schmidt <mschmidt@...hat.com>

diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 44a2270..98014c0 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -3938,8 +3938,10 @@ static u16 issuecommand(struct airo_info *ai, Cmd *pCmd, Resp *pRsp) {
 		if ((IN4500(ai, COMMAND)) == pCmd->cmd)
 			// PC4500 didn't notice command, try again
 			OUT4500(ai, COMMAND, pCmd->cmd);
+#ifndef CONFIG_PREEMPT_HARDIRQS
 		if (!in_atomic() && (max_tries & 255) == 0)
 			schedule();
+#endif
 	}

 	if ( max_tries == -1 ) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/