Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752152AbdLMIx6 (ORCPT ); Wed, 13 Dec 2017 03:53:58 -0500 Received: from smtp2200-217.mail.aliyun.com ([121.197.200.217]:48491 "EHLO smtp2200-217.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882AbdLMIxx (ORCPT ); Wed, 13 Dec 2017 03:53:53 -0500 X-Alimail-AntiSpam: AC=CONTINUE;BC=0.08244962|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03300;MF=ren_guo@c-sky.com;NM=1;PH=DS;RN=22;RT=22;SR=0;TI=SMTPD_---.9hhnDAq_1513155216; Date: Wed, 13 Dec 2017 16:53:36 +0800 From: Guo Ren To: Greentime Hu Cc: Greentime , Linux Kernel Mailing List , Arnd Bergmann , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , netdev , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Vincent Chen Subject: Re: [PATCH v3 09/33] nds32: Cache and TLB routines Message-ID: <20171213085334.GA21382@gary-OptiPlex-3050> References: <9d0e976c3e60bf6834dffb6ef798ad2a03e1c9ac.1512723245.git.green.hu@gmail.com> <20171213021619.GA6254@gary-OptiPlex-3050> <20171213081949.GA18840@gary-OptiPlex-3050> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1214 Lines: 34 On Wed, Dec 13, 2017 at 04:30:41PM +0800, Greentime Hu wrote: > 2017-12-13 16:19 GMT+08:00 Guo Ren : > > On Wed, Dec 13, 2017 at 01:45:02PM +0800, Greentime Hu wrote: > > > >> I think it should be fine if an interruption between mtsr_dsb and > >> tlbop_rwr because this is a optimization by sw. > > > > Fine? When there is an unexpected vaddr in SR_TLB_VPN, tlbop_rwr(*pte) will > > break that vaddr's pfn in the CPU tlb-buffer entry. When linux access the > > vaddr, it will get wrong data unless the entry has been replaced out. > > Hi, Guo Ren: > > Thanks. I get your point. > It is needed to be protected. > I will fix it in the next version patch. > > if (vma->vm_mm == current->active_mm) { > local_irq_save(flags); > __nds32__mtsr_dsb(addr, NDS32_SR_TLB_VPN); > __nds32__tlbop_rwr(*pte); > __nds32__isb(); > local_irq_restore(flags); > } If hardware tlbop_rwr could invalid NDS32_SR_TLB_VPN, then you needn't protect. I mean: mtsr addr1 NDS32_SR_TLB_VPN mtsr addr2 NDS32_SR_TLB_VPN tlbop_rwr(*pte) // OK, and it will hit a hardware invalid bit internal. tlbop_rwr(*pte) // SR_TLB_VPN invalided, then it will not cause problem. :) How my idea?