linux-kernel - Re: PATCH: 2.6.26-rc8: Fix IRQF_DISABLED for shared interrupts

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]

Message-Id: <200806292009.26975.david-b@pacbell.net>
Date:	Sun, 29 Jun 2008 20:09:26 -0700
From:	David Brownell <david-b@...bell.net>
To:	Stefan Becker <Stefan.Becker@...ia.com>
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
	ext Alan Stern <stern@...land.harvard.edu>
Subject: Re: PATCH: 2.6.26-rc8: Fix IRQF_DISABLED for shared interrupts

On Sunday 29 June 2008, Stefan Becker wrote:
> The problem is caused by this code in handle_IRQ_event():
> 
>         if (!(action->flags & IRQF_DISABLED))
>                 local_irq_enable_in_hardirq();
> 
>         do {
>                 ret = action->handler(irq, action->dev_id);
>          ...
>                 action = action->next;
>         } while (action);
> 
> For shared interrupts IRQF_DISABLED will only take effect if the first 
> registered handler sets it.

I was suspecting something rude like that ...

By the way, did you notice the oddness of IRQF_SAMPLE_RANDOM there?
For a shared IRQ, I would rather think that if any IRQ was flagged
as "too predictable for use as IRQ randomness" (by not having that
flag set) then the IRQ should never be sampled ... there's some odd
thought (or non-thought) involved in IRQ sharing.

> The attached changes fix the problem for me.

And it looks plausible to me.  Seems like this patch (or a variant)
should be merged for 2.6.26-final, yes?  Disregarding IRQF_DISABLED
has -- as you noted -- significant potential for oopsage.

I suggest you provide a fully cleaned-up version of this patch with
your signed-off-by line and a proper patch description ... do this
ASAP, since RC8 is getting a bit late for patches to merge!

One technical comment:

> --- a/kernel/irq/internals.h
> +++ b/kernel/irq/internals.h
> @@ -2,6 +2,13 @@
>   * IRQ subsystem internal functions and variables:
>   */
>  
> +/*
> + * Internal interrupt flags
> + *
> + * IRQF_DISABLED_CUMULATIVE - one handler in the chain has IRQF_DISABLED
> set + */
> +#define IRQF_DISABLED_CUMULATIVE       0x80000000
> +
>  extern int noirqdebug;
>  
>  /* Set default functions for irq_chip structures: */

I don't think you should need that flag; and if you did, it should be
declared in <linux/irq.h> to prevent anyone else from using that bit
for some other purpose.

Instead, I think you can set IRQF_DISABLED in irq_desc[irq].status
to achieve the same effect.

- Dave

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