linux-kernel - Re: [PATCH] X86: Change the default value of nr_irqs from 32 to NR

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: <48AB241A.4030706@citrix.com>
Date:	Tue, 19 Aug 2008 20:50:50 +0100
From:	Alex Nixon <alex.nixon@...rix.com>
To:	Yinghai Lu <yhlu.kernel@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] X86: Change the default value of nr_irqs from 32 to NR_IRQs

Yinghai Lu wrote:
> On Tue, Aug 19, 2008 at 11:32 AM, Alex Nixon <alex.nixon@...rix.com> wrote:
>> Yinghai Lu wrote:
>>> On Tue, Aug 19, 2008 at 11:13 AM, Alex Nixon (Intern)
>>> <Alex.Nixon@...rix.com> wrote:
>>>> Yinghai Lu <yhlu.kernel@...il.com> wrote:
>>>>> On Tue, Aug 19, 2008 at 9:55 AM, Alex Nixon <alex.nixon@...rix.com>
>>>>> wrote:
>>>>>> If the number of discovered IRQs is suspiciously low, this patch causes
>>>>>> the number reported to default to NR_IRQS, rather than 32.  NR_IRQS has
>>>>>> already been defined to be a >sensible value for the current system (in
>>>>>> particular, at least 224 when paravirtualisation is involved).
>>>>>>
>>>>> if only one ioapic, nr will be 24<<1, you will get 48. Does pv has io
>>>>> apic
>>>>> ?
>>>>>
>>>>> YH
>>>>>
>>>> I'm not sure about the general case, but Xen does not (Jeremy correct me
>>>> if
>>>> I'm wrong).
>>>>
>>>> Unless I'm missing something (which I may well be; I'm new to this area
>>>> of
>>>> code), it seems more logical anyway to default back to the calculated
>>>> system-specific value (NR_IRQS), instead of 32, which seems rather
>>>> arbitrary.
>>> can you try !CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_SPARSE_IRQ ?
>>>
>>> YH
>> Sorry I should have mentioned originally - the bug occurs both with
>> CONFIG_HAVE_SPARSE_IRQ enabled, and disabled.
> 
> maybe we need special probe_nr_irqs for PV or not call that in
> setup_arch for xen -- it will leave nr_irqs == NR_IRQS
> 
> YH

That would be one solution, but would be more involved than this trivial 
patch (although if considered more 'correct' then it is of course worth 
the effort).
   But attempting to keep things simple, is there a reason it's 
preferable to fall back to 32 rather NR_IRQS?

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