linux-kernel - Re: [3/5] 2.6.21-rc4: known regressions (v2)

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: <m1r6rbz7mg.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 26 Mar 2007 21:29:43 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	"Thomas Meyer" <thomas@...3r.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<linux-pci@...ey.karlin.mff.cuni.cz>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Len Brown" <lenb@...nel.org>
Subject: Re: [3/5] 2.6.21-rc4: known regressions (v2)

"Luck, Tony" <tony.luck@...el.com> writes:

>> What I'm proposing we do is move the irq allocation code out of
>> pci_enable_device and the irq freeing code out of pci_disable_device
>> in the future.
>
> Sounds rational ... in a world that wasn't dominated by PCI it would
> seem to be the logical approach (since the irq code would have much
> more utility independent of the PCI code).

Right.  We can even do this earlier in the pci code.  Just doing this
on demand when the device driver needs it is problematic.  As devices
drivers like to keep the requested over a pci_disable_device pci_enable_device
pair.

The big practical issue is that we will like wind up allocating an irq
number to all usable irqs on ia64.  Which means we will like need many
more irq numbers...  Although I guess if we keep it at the pci layer
we should be fairly safe.

I was afraid there was some hotplug reason for waiting until pci_enable_device
to allocate the irq numbers.

>> Tony, Len before we merge any fixes for 2.6.21-rcX I'd like to at
>> least get an ack on the long term direction.
>
> Long-term-direction-acked-by: Tony Luck <tony.luck@...el.com>

Thanks.  Then small surgery will happen now, and I will start queuing up
the major surgery patches.  Although I won't be able to do more than
compile test and code review the ia64 changes.

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