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]
Date:	Thu, 23 Apr 2009 08:13:04 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, yannick.roehlly@...e.fr
Subject: Re: [RFC PATCH 1/2] pci: don't assume pref memio are 64bit -v3

Ivan Kokshaysky wrote:
> On Wed, Apr 22, 2009 at 07:10:29PM -0700, Yinghai Lu wrote:
>> also on AMD system with two ht chain, or other system with pci=use_crs to get correct root default res,
>> will get anonying
>>
>> PCI: allocations above 4G disabled
>>
>> even the system does support that.
> 
> Yep, but it's easy to fix (patch applies on the top of the previous one).

another case: one system with 8g ram install, one device on bus 0 does get res assigned, but one res from it does support
64bit mmio. and at that case the assign_unassigned code still could assign 64 res to it.
but kernel will still print out that warning.

> 
>> also will have problem with some calling like request_resource(&iomem_resource, ....)
> 
> I don't think so. All critical resources are inserted much earlier than
> mem64 one, and request_resource(&iomem_resource, ...) at later stages
> would most likely fail regardless of mem64 thing.
> Or am I missing something?

at least the one in mm/memory_hotplug.c

/* add this memory to iomem resource */
static struct resource *register_memory_resource(u64 start, u64 size)
{
        struct resource *res;
        res = kzalloc(sizeof(struct resource), GFP_KERNEL);
        BUG_ON(!res);

        res->name = "System RAM";
        res->start = start;
        res->end = start + size - 1;
        res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
        if (request_resource(&iomem_resource, res) < 0) {
                printk("System RAM resource %llx - %llx cannot be added\n",
                (unsigned long long)res->start, (unsigned long long)res->end);
                kfree(res);
                res = NULL;
        }
        return res;
}



> 
> Ivan.
> 
> diff --git a/arch/x86/pci/dac_64bit.c b/arch/x86/pci/dac_64bit.c
> index ee03c4a..35ffee3 100644
> --- a/arch/x86/pci/dac_64bit.c
> +++ b/arch/x86/pci/dac_64bit.c
> @@ -33,12 +33,16 @@ void pcibios_pci64_setup(void)
>  void pcibios_pci64_verify(void)
>  {
>  	struct pci_bus *b;
> +	int disabled = 0;
>  
>  	if (mem64.flags & IORESOURCE_MEM64)
>  		return;		/* presumably DAC works */
>  	list_for_each_entry(b, &pci_root_buses, node) {
> -		if (b->resource[2] == &mem64)
> +		if (b->resource[2] == &mem64) {
>  			b->resource[2] = NULL;
> +			disabled = 1;
> +		}
>  	}
> -	printk(KERN_INFO "PCI: allocations above 4G disabled\n");
> +	if (disabled)
> +		printk(KERN_INFO "PCI: allocations above 4G disabled\n");
>  }

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ