Re: Have any influence on set_memory_** about below patch ??

From	Xishi Qiu <qiuxishi@huawei.com>
Newsgroups	linux.kernel
Subject	Re: Have any influence on set_memory_** about below patch ??
Date	2016-01-27 02:30 +0100
Message-ID	<qVn5M-4lp-9@gated-at.bofh.it> (permalink)
References	(1 earlier) <qPVWy-2fD-23@gated-at.bofh.it> <qPVWy-2fD-19@gated-at.bofh.it> <qQ59w-8S-29@gated-at.bofh.it> <qQlR0-3iC-5@gated-at.bofh.it> <qQrMJ-7nW-11@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On 2016/1/13 19:28, Mark Rutland wrote:

> On Wed, Jan 13, 2016 at 01:02:31PM +0800, Xishi Qiu wrote:
>> Hi Mark,
>>
>> If I do like this, does it have the problem too?
>>
>> kmalloc a size
>> no access
>> flush tlb
>> call set_memory_ro to change the page table flag
>> flush tlb
>> start access
> 
> This is broken.
> 
> The kmalloc will give you memory form the linear mapping. Even if you
> allocate a page, that page could have been mapped with a section at the
> PMD/PUD/PGD level.
> 
> Other data could fall within that section (e.g. a kernel stack,
> perhaps).

Hi Mark,

If nobody use that whole section before(however it is almost impossible),
flush tlb is safe, right?

Thanks,
Xishi Qiu

> 
> Additional TLB flushees do not help. There's still a race against the
> asynchronous TLB logic. The TLB can allocate or destroy entries at any
> tim. If there were no page table changes prior to the invalidate, the
> TLB could re-allocate all existing entries immediately after the TLB
> invalidate, leaving you in the same state as before.
> 
> Thanks,
> Mark.
> 
> .
>

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Re: Have any influence on set_memory_** about below patch ?? Xishi Qiu <qiuxishi@huawei.com> - 2016-01-27 02:30 +0100
  Re: Have any influence on set_memory_** about below patch ?? Mark Rutland <mark.rutland@arm.com> - 2016-01-27 12:30 +0100

csiph-web