Messages in this thread | | | Date | Tue, 12 Aug 2014 15:24:25 +0800 | From | "Zhang, Yanmin" <> | Subject | Re: [PATCH] export the function kmap_flush_unused. |
| |
On 2014/8/11 19:54, Peter Zijlstra wrote: > 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?
Sorry, Peter. Ruibin is a new guy in LKML community. He uses outlook to send emails. He would improve that.
> > 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? No. set_memory_() assumes the memory is not in HIGHMEM. This scenario is driver allocates HIGHMEM pages, which are kmapped before. Kernel uses a lazy method when kunmap a HIGHMEM page. The pages are not unmapped from KMAP page table entries immediately. When next kmap calling uses the same entry, kernel would change pte. Or when change_page_attr_set_clr is called.
Our big driver doesn't call change_page_attr_set_clr when mmap the pages with UNCACHABLE prot. It need call kmap_flush_unused directly after allocating HIGHMEM pages.
Thanks for the kind comments.
Yanmin
| |