From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
"Sha, Ruibin" <ruibin.sha@intel.com>
Cc: Chintan Pandya <cpandya@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"mel@csn.ul.ie" <mel@csn.ul.ie>,
"mgorman@suse.de" <mgorman@suse.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"Zhang, Yanmin" <yanmin.zhang@intel.com>,
"He, Bo" <bo.he@intel.com>
Subject: Re: [PATCH] export the function kmap_flush_unused.
Date: Tue, 12 Aug 2014 15:24:25 +0800 [thread overview]
Message-ID: <53E9C129.2020902@linux.intel.com> (raw)
In-Reply-To: <20140811115431.GW9918@twins.programming.kicks-ass.net>
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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
"Sha, Ruibin" <ruibin.sha@intel.com>
Cc: Chintan Pandya <cpandya@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"mel@csn.ul.ie" <mel@csn.ul.ie>,
"mgorman@suse.de" <mgorman@suse.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"Zhang, Yanmin" <yanmin.zhang@intel.com>,
"He, Bo" <bo.he@intel.com>
Subject: Re: [PATCH] export the function kmap_flush_unused.
Date: Tue, 12 Aug 2014 15:24:25 +0800 [thread overview]
Message-ID: <53E9C129.2020902@linux.intel.com> (raw)
In-Reply-To: <20140811115431.GW9918@twins.programming.kicks-ass.net>
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
next prev parent reply other threads:[~2014-08-12 7:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 9:16 [PATCH] export the function kmap_flush_unused Sha, Ruibin
2014-08-08 13:39 ` Chintan Pandya
2014-08-08 13:39 ` Chintan Pandya
2014-08-11 1:26 ` Sha, Ruibin
2014-08-11 1:26 ` Sha, Ruibin
2014-08-11 3:32 ` Zhang, Yanmin
2014-08-11 3:32 ` Zhang, Yanmin
2014-08-11 11:54 ` Peter Zijlstra
2014-08-12 7:24 ` Zhang, Yanmin [this message]
2014-08-12 7:24 ` Zhang, Yanmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E9C129.2020902@linux.intel.com \
--to=yanmin_zhang@linux.intel.com \
--cc=bo.he@intel.com \
--cc=cpandya@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ruibin.sha@intel.com \
--cc=yanmin.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.