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] [day] [month] [year] [list]

Message-ID: <m1fy7ieetz.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 02 Apr 2007 13:50:00 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	linux-pci@...ey.karlin.mff.cuni.cz,
	"Luck, Tony" <tony.luck@...el.com>,
	"Thomas Meyer" <thomas@...3r.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"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)

Bjorn Helgaas <bjorn.helgaas@...com> writes:

>
> The main reason we wait until pci_enable_device() to allocate an
> IRQ number is that ia64 currently only has about 180 device vectors,
> and there are machines with more PCI slots than that.

If we don't reserve irqs that the hardware doesn't support we should
be able to simply move the allocation and have about the same cost as
we do today.

> I also think it's nice that we don't do anything with a device until
> we have a driver to claim it.  But there certainly have been cases
> where delaying IRQ allocation has caused troubles.

Agreed.  It is the second call to pci_enable_device() by a driver where
things really start to unravel in the wait until we need it plan.

> I really like the idea of moving to the IRQ == GSI model for ia64.
> But of course, we'll have to get rid of the 180-vector limit to
> make that work, too.

Mostly that is a matter of porting the code from x86_64 where that is
already the case.  I'm pretty certain I have worked through all of
the bit issues, but there might be a few small problems that crop up.

If need by I will do the patches as I find time.  But if someone else gets
there before I do that would be great :)

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/