| 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
| ||
|
Message-ID: <4D628B38.7040105@metafoo.de>
Date: Mon, 21 Feb 2011 16:56:40 +0100
From: Lars-Peter Clausen <lars@...afoo.de>
To: Yinghai Lu <yinghai@...nel.org>, tglx@...utronix.de
CC: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:irq/core] genirq: Make nr_irqs runtime expandable
On 02/19/2011 08:07 PM, Yinghai Lu wrote:
> On 02/19/2011 04:15 AM, tip-bot for Thomas Gleixner wrote:
>> Commit-ID: e7bcecb7b1d29b9ad5af939149a945658620ca8f
>> Gitweb: http://git.kernel.org/tip/e7bcecb7b1d29b9ad5af939149a945658620ca8f
>> Author: Thomas Gleixner <tglx@...utronix.de>
>> AuthorDate: Wed, 16 Feb 2011 17:12:57 +0100
>> Committer: Thomas Gleixner <tglx@...utronix.de>
>> CommitDate: Sat, 19 Feb 2011 12:58:06 +0100
>>
>> genirq: Make nr_irqs runtime expandable
>>
>> We face more and more the requirement to expand nr_irqs at
>> runtime. The reason are irq expanders which can not be detected in the
>> early boot stage. So we speculate nr_irqs to have enough room. Further
>> Xen needs extra irq numbers and we really want to avoid adding more
>> "detection" code into the early boot. There is no real good reason why
>> we need to limit nr_irqs at early boot.
>>
>> Allow the allocation code to expand nr_irqs. We have already 8k extra
>> number space in the allocation bitmap, so lets use it.
>>
>> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
>> ---
>> kernel/irq/irqdesc.c | 22 +++++++++++++++++++---
>> 1 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
>> index a250d3a..6f6644f 100644
>> --- a/kernel/irq/irqdesc.c
>> +++ b/kernel/irq/irqdesc.c
>> @@ -206,6 +206,14 @@ struct irq_desc * __ref irq_to_desc_alloc_node(unsigned int irq, int node)
>> return NULL;
>> }
>>
>> +static int irq_expand_nr_irqs(unsigned int cnt)
>> +{
>> + if (nr_irqs + cnt > IRQ_BITMAP_BITS)
>> + return -ENOMEM;
>> + nr_irqs += cnt;
>> + return 0;
>> +}
>> +
>> int __init early_irq_init(void)
>> {
>> int i, initcnt, node = first_online_node;
>> @@ -287,6 +295,12 @@ static inline int alloc_descs(unsigned int start, unsigned int cnt, int node)
>> {
>> return start;
>> }
>> +
>> +static int irq_expand_nr_irqs(unsigned int cnt)
>> +{
>> + return -ENOMEM;
>> +}
>> +
>> #endif /* !CONFIG_SPARSE_IRQ */
>>
>> /* Dynamic interrupt handling */
>> @@ -335,9 +349,11 @@ irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node)
>> if (irq >=0 && start != irq)
>> goto err;
>>
>> - ret = -ENOMEM;
>> - if (start >= nr_irqs)
>> - goto err;
>> + if (start >= nr_irqs) {
>> + ret = irq_expand_nr_irqs(cnt);
>> + if (ret)
>> + goto err;
>> + }
>
> may need following patch.
>
> [PATCH] genirq: use IRQ_BITMAP_BITS as search size
>
> instead of nr_irqs.
>
> Otherwise bitmap_find_next_area could exit with larger start and in extreme
> case we could fail to get wrong irqs return.
>
> For example:
> IRQ_BITMAP_BITS=10240
> nr_irqs=8192
> cnt=2048
>
> and bit 0 to bit 8190 are set already.
>
> before patch start from bit_find_next_area() will be 8191+2048.
> later irq_expand_nr_irqs will set nr_irqs 10240.
> finally irq_alloc_descs will return [8191+2048, 8191+2048+2047] happily..
>
> with this patch, will get correct [8191, 8191+2047]
>
> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>
> ---
> kernel/irq/irqdesc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/kernel/irq/irqdesc.c
> ===================================================================
> --- linux-2.6.orig/kernel/irq/irqdesc.c
> +++ linux-2.6/kernel/irq/irqdesc.c
> @@ -346,12 +346,13 @@ irq_alloc_descs(int irq, unsigned int fr
>
> mutex_lock(&sparse_irq_lock);
>
> - start = bitmap_find_next_zero_area(allocated_irqs, nr_irqs, from, cnt, 0);
> + start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
> + from, cnt, 0);
> ret = -EEXIST;
> if (irq >=0 && start != irq)
> goto err;
>
> - if (start >= nr_irqs) {
> + if (start + cnt > nr_irqs) {
> ret = irq_expand_nr_irqs(cnt);
Just a minor thing, but if there are still unused irqs available at the end of
the current range, you'll end up expanding the range more then you need to.
So either do
irq_expand_nr_irqs(nr_irqs - start + cnt);
or change irq_expand_nr_irqs to let it take the new total number of irqs.
Btw., with this patch in place does it make sense to initialize nr_irqs to
anything else then initcnt in early_irq_init?
> if (ret)
> goto err;
> --
> 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/
--
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