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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Jun 2012 09:02:25 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linus.walleij@...ricsson.com, grant.likely@...retlab.ca,
	Alessandro Zummo <a.zummo@...ertech.it>,
	rtc-linux@...glegroups.com, stable@...r.kernel.org
Subject: Re: [PATCH 01/14] rtc: ab8500-rtc: IRQF_ONESHOT when requesting a
 threaded IRQ

On 14/06/12 08:30, Andrew Morton wrote:
> On Thu, 14 Jun 2012 08:14:49 +0100 Lee Jones<lee.jones@...aro.org>  wrote:
> 
>> On 13/06/12 23:25, Andrew Morton wrote:
>>> On Tue, 12 Jun 2012 09:57:37 +0100
>>> Lee Jones<lee.jones@...aro.org>   wrote:
>>>
>>>> The kernel now forces IRQs to be ONESHOT if no IRQ handler is passed.
>>>
>>> What does this mean.  The kernel crashes?  The registration fails?  A
>>> warning is emitted?
>>>
>>> When fixing a bug, please fully describe the consequences of that bug.
>>>
>>>> Cc: stable@...r.kernel.org
>>>
>>> Especially when suggesting a -stable backport.
>>
>> No problem. I'll try to remember that for next time.
>>
>> I see that you've taken the patch into your tree however. So do you want
>> me to update the commit log and resubmit, or are you going to 'let this
>> one slide'?
> 
> Please read my emails - they're very nice!  "What does this mean.  The
> kernel crashes?  The registration fails?  A warning is emitted?".  You
> answer that, I copy-n-paste into changelog and we're done.

Ah, you're a star!

Registration fails:

> __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
> {
<snip>
> 	if (new->flags & IRQF_ONESHOT) {
<snip>
> 	} else if (new->handler == irq_default_primary_handler) {
> 		/*
> 		 * The interrupt was requested with handler = NULL, so
> 		 * we use the default primary handler for it. But it
> 		 * does not have the oneshot flag set. In combination
> 		 * with level interrupts this is deadly, because the
> 		 * default primary handler just wakes the thread, then
> 		 * the irq lines is reenabled, but the device still
> 		 * has the level irq asserted. Rinse and repeat....
> 		 *
> 		 * While this works for edge type interrupts, we play
> 		 * it safe and reject unconditionally because we can't
> 		 * say for sure which type this interrupt really
> 		 * has. The type flags are unreliable as the
> 		 * underlying chip implementation can override them.
> 		 */
> 		pr_err("Threaded irq requested with handler=NULL and !ONESHOT for irq %d\n", irq);
> 		ret = -EINVAL;
> 		goto out_mask;
> 	}
<snip>

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515 
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ