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  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]
Date:	Mon, 26 Oct 2009 17:20:28 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] pci: only release that resource index is less than 3

Bjorn Helgaas wrote:
> On Mon, 2009-10-26 at 14:23 -0700, Yinghai Lu wrote:
> 
>> ===================================================================
>> --- linux-2.6.orig/drivers/pci/setup-bus.c
>> +++ linux-2.6/drivers/pci/setup-bus.c
>> @@ -322,33 +322,54 @@ static void pci_bridge_check_ranges(stru
>>  	}
>>  }
>>  
>> -/* Helper function for sizing routines: find first available
>> -   bus resource of a given type. Note: we intentionally skip
>> -   the bus resources which have already been assigned (that is,
>> -   have non-NULL parent resource). */
>> -static struct resource *find_free_bus_resource(struct pci_bus *bus, unsigned long type)
>> +void pci_bridge_release_not_used_res(struct pci_bus *bus)
>>  {
>>  	int i;
>>  	struct resource *r;
>>  	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
>>  				  IORESOURCE_PREFETCH;
>>  
>> -	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
>> +	/* for pci bridges res only */
>> +	for (i = 0; i < 3; i++) {
> 
> I think the "i = 0; i < 3" part is to check the bridge apertures, i.e.,
> the I/O base/limit, the memory base/limit, and the prefetchable memory
> base/limit.  Right?  We need some way to indicate that more clearly than
> using a hard-coded "3".

yes. the 0x1c, 0x20, and 0x28

> 
>>  		r = bus->resource[i];
>> -		if (r == &ioport_resource || r == &iomem_resource)
>> -			continue;
>> -		if (r && (r->flags & type_mask) == type) {
>> +		if (r && (r->flags & type_mask)) {
>>  			if (!r->parent)
>> -				return r;
>> +				continue;
>>  			/*
>>  			 * if there is no child under that, we should release
>>  			 * and use it. don't need to reset it, pbus_size_* will
>>  			 * set it again
>>  			 */
>>  			if (!r->child && !release_resource(r))
> 
> We got this resource pointer out of a struct pci_bus, and we release it
> here.  We must have previously done a request_resource(),
> allocate_resource(), or similar.  Where does that happen?  Are the
> requests and releases nested correctly?
> 
> I would think that somewhere, we would be doing a request_resource() and
> assigning the resource to pci_bus->resource[x].  But there are very few
> assignments to the pci_bus resources:
>   setup_resource (only for "pci=use_crs")
>   pci_read_bridge_bases (just a copy from upstream bus resources)
>   pci_alloc_child_bus (copy from upstream bridge resources)
>   pci_create_bus (set to &ioport_resource or &iomem_resource)
> 
> My guess is that this release_resource() releases something we copied
> from the bridge in pci_alloc_child_bus().  But that doesn't seem right,
> because we aren't changing the bridge programming here.

in arch/x86/pci/i386.c::
pcibios_resource_survey() ==> pcibios_allocate_bus_resources()


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

Powered by blists - more mailing lists