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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Oct 2010 09:19:28 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>, x86@...nel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [patch 00/47] Sparse irq rework

On 10/11/2010 01:16 AM, Thomas Gleixner wrote:
> On Sun, 10 Oct 2010, Yinghai Lu wrote:
> 
>> On 10/10/2010 02:32 AM, Thomas Gleixner wrote:
>>> On Sat, 9 Oct 2010, Yinghai Lu wrote:
>>>> On 10/08/2010 11:34 PM, Thomas Gleixner wrote:
>>>>> On Fri, 8 Oct 2010, Yinghai Lu wrote:
>>>>>> +	/* only handle fall out from setup_IO_APIC_irqs() */
>>>>>
>>>>> What's the fallout ? And why are we coming here in the first place
>>>>> when the irq is < 16 ?
>>>>
>>>> setup_IO_APIC_irqs only handle apic_id == 0 or apic_id > 0 but irq < 16 via acpi override.
>>>>
>>>> it seems IBM's system have apic_id == 1, and sci irq is using 30.
>>>>
>>>> so at that time add that setup_IO_APIC_irq_extra() to workaround it.
>>>> but it seems we set that two time when irq < 16.
>>>>
>>>>>
>>>>>> +	if (!((apic_id > 0) && (irq > 16)))
>>>>>> +		return;
>>>
>>> I added this into the queue, but simplified it to 
>>>
>>>   if (apic_id == 0 || irq < NR_IRQS_LEGACY)
>>>
>>> Folded in the other fix and pushed out an updated tree.
>>
>> still have the irq_2_iommu_alloc warning from pnpacpi
> 
> Hmm, that's probably a problem for all legacy interrupts which are
> never torn down once they are set up. And we set them all up during
> early boot.
> 
> So either we special case the legacy area or remove the warning
> alltogether.

or use pr_warning instead of WARN_ONCE?

> 
> Another option I discussed with Suresh recently is to remove the
> allocator in intr_remapping.c and just embedd irq_2_iommu into
> irq_cfg.

in setup_IO_APIC_irqs(), pin_programmed is not set.

                /*
                 * don't mark it in pin_programmed, so later acpi could
                 * set it correctly when irq < 16
                 */
                setup_ioapic_irq(apic_id, pin, irq, cfg, irq_trigger(idx),
                                  irq_polarity(idx));

because we found some systems have strange ioapic setting, their pci devices irq < 16.

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