lkml.org 
[lkml]   [2009]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG 2.6.31-rc1] HIGHMEM64G causes hang in PCI init on 32-bit x86


On Mon, 29 Jun 2009, Yinghai Lu wrote:
> + end = round_up(start, ram_alignment(start)) - 1;
> + if (start > (resource_size_t)end)
> continue;
> - reserve_region_with_split(&iomem_resource, start,
> - end - 1, "RAM buffer");
> + reserve_region_with_split(&iomem_resource, (resource_size_t)start,
> + (resource_size_t)end, "RAM buffer");

Hmm. You shouldn't need the casts with reserve_region_with_split(), and
they just make things uglier.

Also, I wonder if we should do something like this instead

#define MAX_RESOURCE_SIZE ((resource_size_t)-1)

...
end = round_up(start, ram_alignment(start)) - 1;
if (end > MAX_RESOURCE_SIZE)
end = MAX_RESOURCE_SIZE;
if (start > end)
continue;

Because otherwise we'll just be ignoring resources that cross the resource
size boundary, which sounds wrong.

We _could_ have a RAM resource that crosses the 4GB boundary, after all.

Yeah, it doesn't happen much in practice, because usually the 3G-4G range
is left for PCI mappings etc, so we might never hit this in practice, but
still, this sounds like a more correct thing to do.

It also avoids the cast. We simply cap the end to the max that
'resource_size_t' can hold.

That said, I have to admit that I'm getting tired of these bugs that only
happen when we have a 32-bit resource_size_t. So I can understand the
attraction to just forcing it to 64-bit and forgetting about these
irritating issues.

Linus


\
 
 \ /
  Last update: 2009-10-18 23:28    [W:0.150 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site