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

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

On Wed, Jan 13, 2016 at 01:02:31PM +0800, Xishi Qiu wrote:

quoted

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.

.