genirq: Make sparse_irq_lock protect what it should protect
authorThomas Gleixner <tglx@linutronix.de>
Tue, 5 Sep 2017 08:12:20 +0000 (10:12 +0200)
committerThomas Gleixner <tglx@linutronix.de>
Thu, 7 Sep 2017 07:30:38 +0000 (09:30 +0200)
commit12ac1d0f6c3e95732d144ffa65c8b20fbd9aa462
treeca0064b624d62149da9519e08ec7e3201ede185a
parent596a7a1d0989c621c3ae49be73a1d1f9de22eb5a
genirq: Make sparse_irq_lock protect what it should protect

for_each_active_irq() iterates the sparse irq allocation bitmap. The caller
must hold sparse_irq_lock. Several code pathes expect that an active bit in
the sparse bitmap also has a valid interrupt descriptor.

Unfortunately that's not true. The (de)allocation is a two step process,
which holds the sparse_irq_lock only across the queue/remove from the radix
tree and the set/clear in the allocation bitmap.

If a iteration locks sparse_irq_lock between the two steps, then it might
see an active bit but the corresponding irq descriptor is NULL. If that is
dereferenced unconditionally, then the kernel oopses. Of course, all
iterator sites could be audited and fixed, but....

There is no reason why the sparse_irq_lock needs to be dropped between the
two steps, in fact the code becomes simpler when the mutex is held across
both and the semantics become more straight forward, so future problems of
missing NULL pointer checks in the iteration are avoided and all existing
sites are fixed in one go.

Expand the lock held sections so both operations are covered and the bitmap
and the radixtree are in sync.

Fixes: a05a900a51c7 ("genirq: Make sparse_lock a mutex")
Reported-and-tested-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
kernel/irq/irqdesc.c