Re: [PATCH -v3 40/47] PCI: Add pci bus removal through /sys/.../pci_bus/.../remove

[Bjorn Helgaas]

On Fri, Apr 6, 2012 at 11:42 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> adding back the CC list
>
>
> ---------- Forwarded message ----------
> From: Yinghai Lu <yhlu.kernel@xxxxxxxxx>
> Date: Fri, Apr 6, 2012 at 9:24 AM
> Subject: Re: [PATCH -v3 40/47] PCI: Add pci bus removal through
> /sys/.../pci_bus/.../remove
> To: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
>
>
> On Fri, Apr 6, 2012 at 9:07 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>> On Fri, Apr 6, 2012 at 10:01 AM, Yinghai Lu <yhlu.kernel@xxxxxxxxx> wrote:
>>> On Fri, Apr 6, 2012 at 8:50 AM, Jiang Liu <liuj97@xxxxxxxxx> wrote:
>>>> Hi Yinghai,
>>>>        I found many other drivers assume that a pci bus won't disappear if
>>>> the corresponding PCI bridge device still exists. The sysfs interface proposed
>>>> here breaks that assumption and may cause many access-after-free issues.
>>>> So what's the purpose of this interface? Should we remove this interface or
>>>> enhance other drivers to avoid invalid memory access issues?
>>
>> Can you point out some of the specifics about drivers making this
>> assumption?  I'm not thrilled about the idea of removing a pci_bus
>> while the upstream bridge pci_dev still exists either.
>
> I noticed that too. some hotplug driver link to those child bus
> instead of bridge...
> So have prepared some local patches to handle them.

I know you sometimes send patches as attachments because gmail makes
it hard to send them inline.  Gmail also makes it a pain to *review*
things sent as attachments, so it's hard on both ends.  I wish I could
fix that, but I can't.  Attachments also don't show up in patchwork,
which I hope to use to help keep track of things.  Bottom line:
attachments get less attention than they probably deserve.

>>> ok, will make it only show up on root bus.
>>
>> OK.  I'm still interested in the specifics because I don't like the
>> way the pci_bus is exposed, even inside the kernel.  The bus itself is
>> not an active entity, and we can't really do anything with it except
>> by touching a device connected to it.
>
> I want to keep that to remove root bus that is not added acpi root.

What's the use case for this?  I understand there are systems where
you can physically add or remove host bridges by plugging or
unplugging cables.  But in that case, I expect the host bridges to be
ACPI devices, and I expect an ACPI hotplug flow.

But I'm not aware of cases where we can hotplug non-ACPI host bridges,
so I don't understand the value of supporting this.  Is this related
to the cases where we blindly probe and discover CPU memory
controllers and things that the BIOS decided not to expose to the OS?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/