linux-kernel - kernel/irq: __setup_irq/__free

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>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Jan 2010 10:36:31 +0200
From:	Shmulik Ladkani <shmulik.ladkani@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	mingo@...e.hu, yinghai@...nel.org, travis@....com,
	tglx@...utronix.de, peterz@...radead.org
Subject: kernel/irq: __setup_irq/__free_irq disable-depth asymmetry?

Hi,

For discussion simplicity, lets assume our IRQ is not IRQF_SHARED, also
IRQ_NOAUTOEN is not set.

Normally, when the system is initialized, the initial value of
irq_desc[i].depth is 1, representing disable-depth of 1, as the line is
indeed initially disabeled.

When __setup_irq is called (as a result of request_irq call), the line gets
enabled via desc->chip->startup(irq), and desc->depth is set to 0
(meaning: there's no disable-depth).

When __free_irq is called (assuming last handler unregistering), the line
gets masked by desc->chip->shutdown(irq), however the desc->depth is not
modified.
In that case, desc->depth is still 0 ("no disable-depth") but the line is
actually disabled.

Now suppose someone calls disable_irq() and then enable_irq().
The overall result will be the line getting enabled by the latter call,
although there's no registered ISR.
(disable_irq increments depth to 1, enabled_irq decrements it to 0 and
thus calls desc->chip->enable).

Yes, I agree, calling disable_irq/enable_irq when there's no registered ISR
is bizzare... however bizzare things might happen to you too ;)

What bothers me is that the overall result is not identical when running
the following sequence: system initlialization, disable_irq, enable_irq
(without any __setup_irq/__free_irq calls).
In that case, the overall result is that the line is kept masked.
(upon initialization depth is 1, disable_irq increments it to 2, enable_irq
decrements it to back 1. no desc->chip->xxx calls whatsoever).

The cause for this behaviour is the assymetrical treatment to the 'depth' field
in __free_irq; it should have reverted what was done in __setup_irq.

So, I suggest resetting desc->depth to 1 within __free_irq (at the same place
desc->chip->shutdown is called).

Your thoughts appreciated.

-- 
Shmulik Ladkani
--
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/