linux-kernel - Re: 2.6.25-rc8-mm1 panic in rpaphp_register

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: <20080422040502.GB1788@ldl.fc.hp.com>
Date:	Mon, 21 Apr 2008 22:05:02 -0600
From:	Alex Chiang <achiang@...com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, pbadari@...ibm.com,
	linux-kernel@...r.kernel.org, matthew@....cx
Subject: Re: 2.6.25-rc8-mm1 panic in rpaphp_register_slot()

* Benjamin Herrenschmidt <benh@...nel.crashing.org>:
> 
> On Sat, 2008-04-19 at 00:38 -0600, Alex Chiang wrote:
> > So I'm not sure how much we can use of your slot infrastructure, I'll
> > have
> > > to look, I suspect it can cover some cases but not all of them.
> > 
> > *poke*
> > 
> > Any update on this?
> > 
> > Anything I can do to help?
> 
> Not yet no. I've looked a bit, but ran out of time, I'll look more this
> week-end or next week. I'm also trying to figure out who in IBM is
> responsible for that hotplug stuff so they can get involved too.
> 
> BTW. How would you do if the answer was we simply can't declare hotplug
> "slots" ? ie. if I end up finding out (which is what I think will
> happen) that there is simply no way for us to know in advance any
> concept of "slot" with a devfn for hotplug ?

Hm, I may be getting lost in the twisty maze of pseries, but I
guess I don't really understand this statement.

Today, before calling rpaphp_register_slot, we first call
rpaphp_enable_slot. rpaphp_enable_slot makes a call to
pcibios_find_pci_bus which must succeed before we ever try to
register the slot.

So if there is a pci_bus, then it must have a ->self, which means
it has a ->devfn. Right?

Are you saying that it is not accurate to use this
pci_bus->self->devfn to keep track of slots?

> Basically, when doing hotplug, the hypervisor sends us new bits of
> device-tree with things potentially ranging from host bridges, P2P
> bridges to devices, but I'm not certain at this stage we can know in
> advance where they'll hook up (in fact, for PHBs, we can't for sure) and
> thus even if we end up supporting hotplug of actual slots, we don't even
> know in advance the devfn where devices will appear. It's all hidden
> from us by the hypervisor.
> 
> How would that fit in your infrastructure ? Can we just disable usage of
> your slots abstraction in our case ?

I suppose you could just pass in 0 as slot_nr/devfn. That is what
my fixup patch did if it couldn't find a pci_bus->self. The
result would be that for a given pci_bus, you would only see the
first "slot" with this 0 slot_nr appear in sysfs, and it would
have whatever name originally associated with your dn.

I think if I were to understand more about this issue, we could
figure out a better solution...

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/