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

This is a discussion on [RFC] Use kernel_map_pages() to avoid illegal page aliasing. - Kernel ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

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

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

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




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

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

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

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

    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




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

+ Reply to Thread