linux-kernel - Re: genirq: Ensure we locate the passed IRQ in irq_alloc

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:	Fri, 03 Jun 2011 04:24:02 -0500
From:	Milton Miller <miltonm@....com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: genirq: Ensure we locate the passed IRQ in irq_alloc_descs()

On Thu, 02 Jun 2011 17:55:13 -0000, Mark Brown wrote:
> When irq_alloc_descs() is called with no base IRQ specified then it will
> search for a range of IRQs starting from a specified base address. In the
> case where an IRQ is specified it still does this search in order to ensure
> that none of the requested range is already allocated and it still uses the
> from parameter to specify the base for the search. This means that in the
> case where a base is specified but from is zero (which is reasonable as
> any IRQ number is in the range specified by a zero from) the function will
> get confused and try to allocate the first suitably sized block of free IRQs
> it finds.
> 
> Instead use a specified IRQ as the base address for the search, and insist
> that any from that is specified can support that IRQ.
> 
> Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> 
> ---
> kernel/irq/irqdesc.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
> index 886e803..bb53d6c 100644
> --- a/kernel/irq/irqdesc.c
> +++ b/kernel/irq/irqdesc.c
> @@ -346,6 +346,12 @@ irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node)
>  	if (!cnt)
>  		return -EINVAL;
>  
> +	if (irq >= 0) {
> +		if (from > irq)
> +			return -EINVAL;
> +		from = irq;
> +	}
> +
>  	mutex_lock(&sparse_irq_lock);
>  
>  	start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,

and then right after this the code continues:

        ret = -EEXIST;
        if (irq >=0 && start != irq)
                goto err;


This patch enables exactly the calls I want to forbid !  Why do
you need to verify that there are no irqs between from and irq ?
What is your use case?

Change your caller to specify the irq twice if you need a specific irq
block, or if you only need one then use the helper irq_alloc_desc_at.

If you want to change irq_alloc_descs, please make it return -EINVAL
if irq >=0 && from != irq (like I did).

See http://lkml.indiana.edu/hypermail/linux/kernel/1105.3/00739.html
[PATCH RFC 4/4] irq: allow a per-allocation upper limit when allocating irqs

(and yes, I have made the changes based on the feedback but haven't
had time to get back to the series).

Thanks,
milton
QUIT
--
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/