Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1294074 > unrolled thread

Re: [PATCHv6 2/7] pci: child bus alloc fix on constrained resource

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv6 2/7] pci: child bus alloc fix on constrained resource Bjorn Helgaas <helgaas@kernel.org> - 2015-12-17 18:30 +0100
    Re: [PATCHv6 2/7] pci: child bus alloc fix on constrained resource Keith Busch <keith.busch@intel.com> - 2015-12-17 19:00 +0100

#1294074 — Re: [PATCHv6 2/7] pci: child bus alloc fix on constrained resource

Hi Keith,

On Mon, Dec 07, 2015 at 02:32:24PM -0700, Keith Busch wrote:
> Does not allocate a child bus if the new bus number does not fit in the
> parent's bus resource window.
> 
> Signed-off-by: Keith Busch <keith.busch@intel.com>
> ---
>  drivers/pci/probe.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index edb1984..6e29f7a 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -704,6 +704,12 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>  	int i;
>  	int ret;
>  
> +	if (busnr > parent->busn_res.end) {
> +		dev_printk(KERN_DEBUG, &parent->dev,
> +			  "can not alloc bus:%d under %pR\n", busnr,
> +			  &parent->busn_res);
> +		return NULL;

Can you take a look at 1820ffdccb9b ("PCI: Make sure bus number resources
stay within their parents bounds") and 12d8706963f0 ("Revert "PCI: Make
sure bus number resources stay within their parents bounds"")?

This is implemented differently, but it seems like it might expose the same
problem we found with 1820ffdccb9b.

If you could take a look and confirm that "no, this does something
differently than 1820ffdccb9b did" or "yes, this might expose that problem
again," that would help.

Bjorn

> +	}
>  	/*
>  	 * Allocate a new bus, and inherit stuff from the parent..
>  	 */
> -- 
> 2.6.2.307.g37023ba
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1294097

On Thu, Dec 17, 2015 at 11:27:18AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 07, 2015 at 02:32:24PM -0700, Keith Busch wrote:
> > +	if (busnr > parent->busn_res.end) {
> > +		dev_printk(KERN_DEBUG, &parent->dev,
> > +			  "can not alloc bus:%d under %pR\n", busnr,
> > +			  &parent->busn_res);
> > +		return NULL;
> 
> Can you take a look at 1820ffdccb9b ("PCI: Make sure bus number resources
> stay within their parents bounds") and 12d8706963f0 ("Revert "PCI: Make
> sure bus number resources stay within their parents bounds"")?
> 
> This is implemented differently, but it seems like it might expose the same
> problem we found with 1820ffdccb9b.
> 
> If you could take a look and confirm that "no, this does something
> differently than 1820ffdccb9b did" or "yes, this might expose that problem
> again," that would help.

Thank you for the references. I think 1820ffdccb9b had the check too
late, creating the child bus with resource conflicts. That'd probably
make it appear unavailable. But I believe this new proposal will still
break the same setup for a different reason.

We can live with this issue for now if we want to drop this patch from
the series. The only way we encounter a problem is when the config space
aperture is artificially constrained, so I can request the feature be
put on hold while a better fix is developed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web