linux-kernel - Re: post 2.6.26 requires pciehp_slot_with

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: <20080730023842.GA4269@ldl.fc.hp.com>
Date:	Tue, 29 Jul 2008 20:38:42 -0600
From:	Alex Chiang <achiang@...com>
To:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
Cc:	Matthew Wilcox <matthew@....cx>,
	Pierre Ossman <drzeus-list@...eus.cx>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org
Subject: Re: post 2.6.26 requires pciehp_slot_with_bus

* Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>:
> Matthew Wilcox wrote:
>> So we need a way to find if there's already a slot of this
>> name.  I don't see a kobject routine to do that.  Maybe we can
>> do it internally to the pci slot code.

pci_hp_register already does this with get_slot_from_name().

>> Then we need to pick a new name for the kobject if it does
>> collide.  My suggestion is that the second time we find an
>> object named "2", we call it "2dup1" (the third time "2dup2",
>> etc.)  Other opinions I've seen include "2a", "2b", ... or
>> "2-1", "2-2", ... or "2-brokenfw1", "2-brokenfw2".
>
> That looks quite better than using bus number.

I went with:

	- first slot to register gets "2"
	- second slot to register gets "2-1"
	- Mth slot to register gets "2-M"

At first, I thought it would have been better to put this logic
inside of pci_hp_register, since it knows about the collision,
and could just fix stuff up for the caller.

However, the problem is that each hotplug driver can have a
different length for "name", and it got messy quickly.

So, I just patched the two drivers that are known to be
problematic.

Two patches follow, against 2.6.27-rc1.

Compile tested only -- I don't have hardware to replicate this.

I'd say they're somewhere between RFC and requested for
inclusion. I'm certainly not tied to them, just trying to show
some code to implement the approach described above. If we decide
that looking at _RMV + other bits is the way to go, then I'm fine
with that.

It would be great if Pierre and Kenji-san could try them out.

Thanks.

/ac

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