From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933063AbcAMKbU (ORCPT ); Wed, 13 Jan 2016 05:31:20 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:16860 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757260AbcAMKbN (ORCPT ); Wed, 13 Jan 2016 05:31:13 -0500 Message-ID: <5696272E.8090408@huawei.com> Date: Wed, 13 Jan 2016 18:30:06 +0800 From: Xishi Qiu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mark Rutland 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 ?? References: <5693A740.7070408@huawei.com> <20160111133145.GM6499@leverpostej> <569454F6.1060207@huawei.com> <20160112111531.GA4858@leverpostej> In-Reply-To: <20160112111531.GA4858@leverpostej> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.25.179] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5696273E.011E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=512, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 614475d6f2020a8eaf8e49a1fddd65e5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/12 19:15, Mark Rutland wrote: > On Tue, Jan 12, 2016 at 09:20:54AM +0800, Xishi Qiu wrote: >> On 2016/1/11 21:31, Mark Rutland wrote: >> >>> Hi, >>> >>> On Mon, Jan 11, 2016 at 08:59:44PM +0800, zhong jiang wrote: >>>> >>>> http://www.spinics.net/lists/arm-kernel/msg472090.html >>>> >>>> Hi, Can I ask you a question? Say, This patch tells that the section spilting >>>> and merging wiil produce confilct in the liner mapping area. Based on the >>>> situation, Assume that set up page table in 4kb page table way in the liner >>>> mapping area, Does the set_memroy_** will work without any conplict?? >>> >>> I'm not sure I understand the question. >>> >>> I'm also not a fan of responding to off-list queries as information gets >>> lost. >>> >>> Please ask your question on the mailing list. I am more than happy to >>> respond there. >>> >>> Thanks, >>> Mark. >>> >> >> Hi Mark, >> >> In your patch it said "The presence of conflicting TLB entries may result in >> a variety of behaviours detrimental to the system " and "but this(break-before-make >> approach) cannot work for modifications to the swapper page tables that cover the >> kernel text and data." >> >> I'm not quite understand this, why the direct mapping can't work? > > The problem is that the TLB hardware can operate asynchronously to the > rest of the CPU. At any point in time, for any reason, it can decide to > destroy TLB entries, to allocate new ones, or to perform a walk based on > the existing contents of the TLB. > > When the TLB contains conflicting entries, TLB lookups may result in TLB > conflict aborts, or may return an "amalgamation" of the conflicting > entries (e.g. you could get an erroneous output address). > > The direct mapping is in active use (and hence live in TLBs). Modifying > it without break-before-make (BBM) risks the allocation of conflicting > TLB entries. Modifying it with BBM risks unmapping the portion of the > kernel performing the modification, resulting in an unrecoverable abort. > >> flush tlb can't resolve it? > > Flushing the TLB doesn't help because the page table update, TLB > invalidate, and corresponding barrier(s) are separate operations. The > TLB can allocate or destroy entries at any point during the sequence. > > For example, without BBM a page table update would look something like: > > 1) str , [<*pte>] > 2) dsb ish > 3) tlbi vmalle1is > 4) dsb ish > 5) isb > > After step 1, the new pte value may become visible to the TLBs, and the > TLBs may allocate a new entry for it. Until step 4 completes, this entry > may remain active in the TLB, and may conflict with an existing entry. > > If that entry covers the kernel text for steps 2-5, executing the > sequence may result in an unrecoverable TLB conflict abort, or some > other behaviour resulting from an amalgamated TLB, e.g. the I-cache > might fetch instructions from the wrong address such that steps 2-5 > cannot be executed. > > If the kernel doesn't explicitly access the address covered by that pte, > there may still be a problem. The TLB may perform an internal lookup > when performing a page table walk, and could then use an erroneous > result to continue the walk, resulting in a variety of potential issues > (e.g. reading from an MMIO peripheral register). > > BBM avoids the conflict, but as that would mean kernel text and/or data > would be unmapped, you can't execute the code to finish the update. > >> I find x86 does not have this limit. e.g. set_memory_r*. > > I don't know much about x86; it's probably worth asking the x86 guys > about that. It may be that the x86 architecture requires that a conflict > or amalgamation is never visible to software, or it could be that > contemporary implementations happen to provide that property. > > Thanks, > Mark. > Hi Mark, If I create swapper page tables by 4kb, not large page, then I use set_memory_ro() to change the pate table flag, does it have the problem too? Thanks, Xishi Qiu > . >