Re: [PATCH] export the function kmap_flush_unused.

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Mon, Aug 11, 2014 at 01:26:45AM +0000, Sha, Ruibin wrote:
> Hi Chintan,
> Thank you very much for your timely and kindly response and comments.
> 
> Here is more detail about our Scenario:
> 
>     We have a big driver on Android product. The driver allocates lots of
>     DDR pages. When applications mmap a file exported from the driver,
>     driver would mmap the pages to the application space, usually with
>     uncachable prot.
>     On ia32/x86_64 arch, we have to avoid page cache alias issue. When
>     driver allocates the pages, it would change page original mapping in
>     page table with uncachable prot. Sometimes, the allocated page was
>     used by kmap/kunmap. After kunmap, the page is still mapped in KMAP
>     space. The entries in KMAP page table are not cleaned up until a
>     kernel thread flushes the freed KMAP pages(usually it is woken up by kunmap).
>     It means the driver need  force to flush the KMAP page table entries before mapping pages to
>     application space to be used. Otherwise, there is a race to create
>     cache alias.
> 
>     To resolve this issue, we need export function kmap_flush_unused as
>     the driver is compiled as module. Then, the driver calls
>     kmap_flush_unused if the allocated pages are in HIGHMEM and being
>     used by kmap.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

That said, it sounds like you want set_memory_() to call
kmap_flush_unused(). Because this race it not at all specific to your
usage, it could happen to any set_memory_() site, right?

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]