linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Jiang Liu <liuj97@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>, Jiang Liu <jiang.liu@huawei.com>,
	"Rafael J . Wysocki" <rjw@sisk.pl>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Gu Zheng <guz.fnst@cn.fujitsu.com>,
	Toshi Kani <toshi.kani@hp.com>,
	Myron Stowe <myron.stowe@redhat.com>,
	Yijing Wang <wangyijing@huawei.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3, part2 01/20] PCI: introduce hotplug-safe PCI bus iterators
Date: Tue, 25 Jun 2013 20:58:36 -0600	[thread overview]
Message-ID: <CAErSpo7ZhVaj3OY-Eiw=bh+1fve_ZinP-rT_qN6h7OC=u=_RGQ@mail.gmail.com> (raw)
In-Reply-To: <51C32B64.1010608@gmail.com>

On Thu, Jun 20, 2013 at 10:18 AM, Jiang Liu <liuj97@gmail.com> wrote:
> On 06/18/2013 04:06 AM, Bjorn Helgaas wrote:
>> On Sun, May 26, 2013 at 11:52:58PM +0800, Jiang Liu wrote:
>>> Introduce hotplug-safe PCI bus iterators as below, which hold a
>>> reference on the returned PCI bus object.
>>> bool pci_bus_exists(int domain, int busnr);
>>> struct pci_bus *pci_get_bus(int domain, int busnr);
>>> struct pci_bus *pci_get_next_bus(struct pci_bus *from);
>>> struct pci_bus *pci_get_next_root_bus(struct pci_bus *from);
>>> #define for_each_pci_bus(b) for (b = NULL; (b = pci_get_next_bus(b)); )
>>> #define for_each_pci_root_bus(b)  \
>>>              for (b = NULL; (b = pci_get_next_root_bus(b)); )
>>>
>>> The long-term goal is to remove hotplug-unsafe pci_find_bus(),
>>> pci_find_next_bus() and the global pci_root_buses list.
>>
>> I think you should mark the unsafe interfaces as __deprecated so
>> users will get compile-time warnings.
>>
>> I don't think pci_bus_exists() is a safe interface, because the value
>> it returns may be incorrect before the caller can look at it.  The
>> only safe thing would be to make it so we try to create the bus
>> and return failure if it already exists.  Then the mutex can be in
>> the code that creates the bus.
>>
>> I don't see any uses of for_each_pci_bus(), so please remove that.
>>
>> It sounds like we don't have a consensus on how to iterate over
>> PCI root buses.  If you separate that from the pci_get_bus()
>> changes, maybe we can at least move forward on the pci_get_bus()
>> stuff.
> Hi Bjorn and Yinghai,
>     I have thought about the way to implement pci_for_each_root_bus()
> again. And there are several possible ways here:
> 1) Yinghai has a patch set implementing an iterator for PCI host
> bridges, but we can't safely refer the PCI root bus associated with a
> host bridge device because the host bridge doesn't hold a reference to
> associated PCI root bus. So we need to find a safe way to refer the PCI
> root bus associated with a PCI host bridge.
> 2) Unexport pci_root_buses and convert it to klist, then we could walk
> all root buses effectively. This solution is straight-forward, but it
> may break out of tree drivers.
> 3) Keep current implementation, which does waste some computation cycles:(
>
> So what's your thoughts about above solutions? Or any other suggestions?
> Regards!
> Gerry

Iteration is generally the wrong approach because it doesn't fit well
with hot plug.  I recognize that it may be impossible to fix all the
places that currently iterate over root buses, so we may have to
accept iteration at least in the short term.

Sometimes when we fix the things we *know* how to fix, it makes it
easier to see how to fix the hard problem.  Your pci_bus ref counting
fixes seem like a clear step forward, and I'd like to get them in
ASAP, even if the root bus iteration isn't figured out yet.

So my advice is, let's do the simple stuff we know how to do now, then
worry about the harder stuff later.

Bjorn

  reply	other threads:[~2013-06-26  2:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-26 15:52 [PATCH v3, part2 00/20] Introduce hotplug-safe PCI bus iterators Jiang Liu
2013-05-26 15:52 ` [PATCH v3, part2 01/20] PCI: introduce " Jiang Liu
2013-05-28  4:22   ` Yinghai Lu
2013-05-28 15:06     ` Liu Jiang
2013-06-17 20:06   ` Bjorn Helgaas
2013-06-18 16:23     ` Jiang Liu
2013-06-20 16:18     ` Jiang Liu
2013-06-26  2:58       ` Bjorn Helgaas [this message]
2013-05-26 15:52 ` [PATCH v3, part2 02/20] PCI, core: use hotplug-safe iterators to walk PCI buses Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 03/20] PCI, hotplug: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 04/20] PCI, IOV: hold a reference to PCI bus when creating virtual PCI devices Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 05/20] PCI, Alpha: use hotplug-safe iterators to walk PCI buses Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 06/20] PCI, FRV: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 07/20] PCI, IA64: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 08/20] PCI, Microblaze: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 09/20] PCI, mn10300: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 10/20] PCI, PPC: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 11/20] PCI, SPARC: " Jiang Liu
2013-05-26 17:11   ` David Miller
2013-05-26 15:53 ` [PATCH v3, part2 12/20] PCI, x86: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 13/20] PCI, ACPI: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 14/20] PCI, DRM: " Jiang Liu
2013-06-17 18:08   ` Bjorn Helgaas
2013-05-26 15:53 ` [PATCH v3, part2 15/20] PCI, EDAC: use hotplug-safe PCI bus " Jiang Liu
2013-06-17 20:18   ` Bjorn Helgaas
2013-06-18 16:33     ` Jiang Liu
2013-06-26  3:00       ` Bjorn Helgaas
2013-05-26 15:53 ` [PATCH v3, part2 16/20] PCI, via-camera: use hotplug-safe " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 17/20] PCI, iommu: " Jiang Liu
2013-06-17 20:20   ` Bjorn Helgaas
2013-06-17 20:34     ` Don Dutile
2013-06-18 16:34       ` Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 18/20] PCI, eeepc-laptop: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 19/20] PCI, asus-wmi: " Jiang Liu
2013-05-26 15:53 ` [PATCH v3, part2 20/20] PCI, ARM: use hotplug-safe PCI bus " Jiang Liu
2013-06-17 18:24   ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAErSpo7ZhVaj3OY-Eiw=bh+1fve_ZinP-rT_qN6h7OC=u=_RGQ@mail.gmail.com' \
    --to=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liuj97@gmail.com \
    --cc=myron.stowe@redhat.com \
    --cc=rjw@sisk.pl \
    --cc=toshi.kani@hp.com \
    --cc=wangyijing@huawei.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).