Re: [PATCH 1/2] x86: ioremap: fix wrong physical address handling

From: Kenji Kaneshige
Date: Thu Jun 17 2010 - 20:33:30 EST


(2010/06/17 22:46), H. Peter Anvin wrote:
On 06/17/2010 02:35 AM, Jeremy Fitzhardinge wrote:

By the way, is there linux kernel limit regarding above 44-bits physical
address in x86_32 PAE? For example, pfn above 32-bits is not supported?

That's an awkward situation. I would tend to suggest that you not
support this type of machine with a 32-bit kernel. Is it a sparse
memory system, or is there a device mapped in that range?

I guess it would be possible to special-case ioremap to allow the
creation of such mappings, but I don't know what kind of system-wide
fallout would happen as a result. The consequences of something trying
to extract a pfn from one of those ptes would be

There are probably places at which PFNs are held in 32-bit numbers,
although it would be good to track them down if it isn't too expensive
to fix them (i.e. doesn't affect generic code.)


There are many places which hold pfns in 32 bit variables on 32 bit
systems; the standard type for pfns is "unsigned long", pretty much
everywhere in the kernel. It might be worth defining a pfn_t and
converting usage over to that, but it would be a pervasive change.


I think you're right, and just making 2^44 work correctly would be good
enough. Doing special forwarding of all 52 bits of the real physical
address in the paravirt case (where it is self-contained and doesn't
spill into the rest of the kernel) would probably be a good thing, though.

-hpa


I'll focus on making 2^44 work correctly. Then, I'll do the following
change in the next version of my patch.

- The v.2 patch uses resource_size_t for pfn. I'll keep using
resource_size_t for pfn also in v.3, because there is no reason to
leave it being "unsigned long".

- Use PHYSICAL_PAGE_MASK for masking physical address as v.1 patch
did. I think changing the definition of PAGE_MASK is a little risky.

Thanks,
Kenji Kaneshige


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/