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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ