[RFC] Use kernel_map_pages() to avoid illegal page aliasing.

[RFC] Use kernel_map_pages() to avoid illegal page aliasing.

[Thomas Hellström]

Hi!

For a long time now, the agpgart module has been creating illegal 
mapping aliases, since the user-space mappings of the pages in the gart 
are usually write-combined, whereas the kernel linear mapping of the 
same pages are uc for x86, and may even be wb for some architectures.

In order to fix this, and to facilitate fast insertion and removal of 
pages into / from the gart I'd like to disable all default kernel 
mappings for those pages, which would in effect, make them behave as 
highmem pages from our point of view.

As prevously discussed, the x86 set_memory_xxx() interface wasn't 
suitable for this, since it handles only a single mapping, and the pages 
may have more than one default kernel mapping.

But it turns out that there is an interface that does exactly this. 
kernel_map_pages(). But it is only available  with 
CONFIG_DEBUG_PAGEALLOC. I'd like to make that function exported by 
default, but with some minor alterations as the original functions does 
some debug checks as well, that aren't desirable for the purpose 
mentioned above:

As with highmem pages, if the driver sets up user-space mappings with 
non-standard caching attributes, those mappings need to be killed at 
suspend time, since the suspend code would otherwise create temporary 
incompatible mappings.

On x86 this all would probably work fine. Does kernel_map_pages() work 
identically on other architectures? Specifically: Will it always work 
with a 4K page granularity?

Thanks,
Thomas


/*
* Enable / disable all default kernel mappings of a number of contigous 
pages.
* This is an alias for kernel_map_pages() but with debug checks removed.
*/

int kernel_default_map_pages(struct page *page, int numpages, int enable);
EXPORT_SYMBOL(kernel_default_map_pages);

/*
* Enable / disable all default kernel mappings of a number of single pages.
*/
int kernel_default_map_pagearray(struct page **pages, int numpages, int 
enable);
EXPORT_SYMBOL(kernel_default_map_pagearray);

Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

[Jeremy Fitzhardinge]

Thomas Hellström wrote:
> Hi!
>
> For a long time now, the agpgart module has been creating illegal 
> mapping aliases, since the user-space mappings of the pages in the 
> gart are usually write-combined, whereas the kernel linear mapping of 
> the same pages are uc for x86, and may even be wb for some architectures.
>
> In order to fix this, and to facilitate fast insertion and removal of 
> pages into / from the gart I'd like to disable all default kernel 
> mappings for those pages, which would in effect, make them behave as 
> highmem pages from our point of view.
>
> As prevously discussed, the x86 set_memory_xxx() interface wasn't 
> suitable for this, since it handles only a single mapping, and the 
> pages may have more than one default kernel mapping.
>
> But it turns out that there is an interface that does exactly this. 
> kernel_map_pages(). But it is only available  with 
> CONFIG_DEBUG_PAGEALLOC. I'd like to make that function exported by 
> default, but with some minor alterations as the original functions 
> does some debug checks as well, that aren't desirable for the purpose 
> mentioned above:
>
> As with highmem pages, if the driver sets up user-space mappings with 
> non-standard caching attributes, those mappings need to be killed at 
> suspend time, since the suspend code would otherwise create temporary 
> incompatible mappings.
>
> On x86 this all would probably work fine. Does kernel_map_pages() work 
> identically on other architectures? Specifically: Will it always work 
> with a 4K page granularity?

Well, not all architectures use 4k as their base page size, but 
kernel_map_pages should work at the smallest supported page size.

The disadvantage of this is that it will end up shattering any 
large-page mappings the kernel has.  This is pretty much unavoidable 
unless you can arrange to only allocate AGP pages in a physically 
distinct area away from other kernel allocations (a mechanism to do this 
might be generally useful, though I'm not sure what form it would take - 
another zone perhaps?).

    J

Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

[Thomas Hellström]

Jeremy Fitzhardinge wrote:
> Thomas Hellström wrote:
>> Hi!
>>
>> For a long time now, the agpgart module has been creating illegal 
>> mapping aliases, since the user-space mappings of the pages in the 
>> gart are usually write-combined, whereas the kernel linear mapping of 
>> the same pages are uc for x86, and may even be wb for some 
>> architectures.
>>
>> In order to fix this, and to facilitate fast insertion and removal of 
>> pages into / from the gart I'd like to disable all default kernel 
>> mappings for those pages, which would in effect, make them behave as 
>> highmem pages from our point of view.
>>
>> As prevously discussed, the x86 set_memory_xxx() interface wasn't 
>> suitable for this, since it handles only a single mapping, and the 
>> pages may have more than one default kernel mapping.
>>
>> But it turns out that there is an interface that does exactly this. 
>> kernel_map_pages(). But it is only available  with 
>> CONFIG_DEBUG_PAGEALLOC. I'd like to make that function exported by 
>> default, but with some minor alterations as the original functions 
>> does some debug checks as well, that aren't desirable for the purpose 
>> mentioned above:
>>
>> As with highmem pages, if the driver sets up user-space mappings with 
>> non-standard caching attributes, those mappings need to be killed at 
>> suspend time, since the suspend code would otherwise create temporary 
>> incompatible mappings.
>>
>> On x86 this all would probably work fine. Does kernel_map_pages() 
>> work identically on other architectures? Specifically: Will it always 
>> work with a 4K page granularity?
>
> Well, not all architectures use 4k as their base page size, but 
> kernel_map_pages should work at the smallest supported page size.
>
> The disadvantage of this is that it will end up shattering any 
> large-page mappings the kernel has.  This is pretty much unavoidable 
> unless you can arrange to only allocate AGP pages in a physically 
> distinct area away from other kernel allocations (a mechanism to do 
> this might be generally useful, though I'm not sure what form it would 
> take - another zone perhaps?).
>
>    J
Thanks for the info. Yes, we've had to live with the splitting of large 
pages for some time. In the future we'll probably set up a pool of video 
pages into which we might perhaps try to allocate highmem pages or try 
allocations with large page sizes. In the end perhaps another zone will 
be needed.

/Thomas