linux-kernel - Re: [RFC][PATCH] IRQ: Fix oneshot irq race between irq_finalize_oneshot and handle_level

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 09 Mar 2010 23:48:53 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Valdis.Kletnieks@...edu, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] IRQ: Fix oneshot irq race between irq_finalize_oneshot
 and handle_level_irq

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Gleixner wrote:
> On Tue, 9 Mar 2010, Valdis.Kletnieks@...edu wrote:
>> On Tue, 09 Mar 2010 08:58:11 +0100, Thomas Gleixner said:
>>> On Tue, 9 Mar 2010, Lars-Peter Clausen wrote:
>>>
>>>> If the kernel has been compiled with preemtion support and
handle_level_irq is
>>>> called from process context for a oneshot irq there is a race between
>>>> irq_finalize_oneshot and handle_level_irq which results in the irq
not being
>>>> unmasked after its handlers have been run.
>>>>
>>>> irq_finalize_oneshot is expected to unmask the irq after the
threaded irq
>>>> handler has been run. It only does so if IRQ_MASKED is set for the
irqs status.
>>>> IRQ_MASKED gets set in the lower part of handle_level_irq after
handle_IRQ_event
>>>> has been called.
>>>> handle_IRQ_event will wakeup the oneshot irqs threaded handler and
if the
>>>> kernel has been build with preemption there is a chance that the
threaded irq
>>>> handler will finish before execution is returned to handle_level_irq.
>>>> As a result irq_finalize_oneshot will not unmask the irq and
handle_level_irq
>>>> will set the IRQ_MASKED flag. Thus the irq will stay masked and stalls.
>>>>
>>>> In case of an race the call-graph would look like this:
>>>>  handle_level_irq
>>>>  |- mask_ack_irq
>>>>  |- handle_IRQ_event
>>>>     |- wake_up_process
>>>>        |- irq_thread
>>>>           |- action->thread_fn
>>>>           |- irq_finalize_oneshot # Does not unmask the irq
>>>> |- # Set IRQ_MASKED status flag
>>> Errm, a thread _CANNOT_ preempt a hard interrupt handler.
>> What stops the thread from concurrently running on another CPU and racing
>> that way?  I'm an idiot, use small words. :)
>
> Right it's a valid SMP problem, but I got confused by the lengthy
> explanation of a thread preempting an hard interrupt handler. :)
Yes, sorry for bothering you with that. I actually had the symptoms
described on a non SMP system. The irq in question was part of a
longer irq chain and I though that it might be detached from the
hardirq context somewhere along the chain.
After your comment I reread some parts and it turned out that
irq_enter()/irq_exit() was missing around the first level irq handler.

- - Lars
>
> Will have a look after dinner.
>
> Thanks,
>
>     tglx
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuW0FUACgkQBX4mSR26RiOiSgCfUJJM6i8rEoiifuY5LwoOaJnA
kfAAnjHh5us4m8NgPEV2wYkyIPh7zzly
=R/J/
-----END PGP SIGNATURE-----

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