From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758764AbcAML2g (ORCPT ); Wed, 13 Jan 2016 06:28:36 -0500 Received: from foss.arm.com ([217.140.101.70]:40085 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757235AbcAML2e (ORCPT ); Wed, 13 Jan 2016 06:28:34 -0500 Date: Wed, 13 Jan 2016 11:28:13 +0000 From: Mark Rutland To: Xishi Qiu Cc: zhong jiang , Laura Abbott , Hanjun Guo , "linux-arm-kernel@lists.infradead.org" , LKML Subject: Re: Have any influence on set_memory_** about below patch ?? Message-ID: <20160113112813.GE23370@leverpostej> References: <5693A740.7070408@huawei.com> <20160111133145.GM6499@leverpostej> <569454F6.1060207@huawei.com> <20160112111531.GA4858@leverpostej> <5695DA67.5080201@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5695DA67.5080201@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). 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.