Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp857369pxb; Fri, 22 Jan 2021 00:30:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJx5prYopywnVnFO54OwPFwBEkdm1UCMqJidLGCSGnmNIJcZ3VTMU5vuGzlhaig/166kiF0a X-Received: by 2002:a17:906:2743:: with SMTP id a3mr2300887ejd.378.1611304235300; Fri, 22 Jan 2021 00:30:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611304235; cv=none; d=google.com; s=arc-20160816; b=y+RLlCGAnTTX87hgztoYx23efdZHaDCH9wmD9c3ipUVfDfgrTEa8KcYNqVMW8uwfJA qNU4ceOWTKk43jeVcxRwkDfIN7wEsxrQMXZMDWJoJ3dc541p3w0noFP/5RIni1KSTzIe P2sCFDeB0qy6mZyuV4xSVifq0Ktn6SJQcd1X8wOSWBtsXxCphAdoxyLuxWL96wj5PqNj sQrZbfJ7sN6nqkKQyY2e8vyrkA4Rcg74cFPK1qeGd26ibaScYSZp3KUdxaztIL19LFf0 zyoxALROs0DWNAslWW1WG9fTEAegI1Pb/E3A4sk492ofYmg8P1CVTRRxS5JfuIOr8Mau GmbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=NLKm8bpMMxcfS/L3t0aLWFs7kdp+Tm3HrN2Rsomy/do=; b=dr/oOBUJirjyyzFt8JklvXZdBCR3Zvt9fzqAnNgri8QIDSQhHatipwJtfqLxJzbswG IwLuBZf+Npt2o2Gyy7U+uIa1w3g9a3czpEX35Gt5P+3wijJGjyMC9PPyGilPYjERbLNN CVZ1fSm7FuQ8DhsicFJqmsWd+t5ZEBP4z7DJVFrsXoCmUavPrzeC1b9Sq+dZhevmsJPQ ugGDtEANVa9iiwooRh3p/Fd9uuPHKFyMQmC/cCAAH83BcglaCBivGLdZVQUXbBruAlqt m3km2VmhUxE6rSgpba4XCufBYqK9qqKSNz6Igz96Pma0vTUSQmqmrZ5xsg2Q/FVJH7UF AXcw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si3162352edq.456.2021.01.22.00.30.11; Fri, 22 Jan 2021 00:30:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726299AbhAVI2j (ORCPT + 99 others); Fri, 22 Jan 2021 03:28:39 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11178 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727006AbhAVI2H (ORCPT ); Fri, 22 Jan 2021 03:28:07 -0500 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DMXQZ5clkzl7Vt; Fri, 22 Jan 2021 16:25:58 +0800 (CST) Received: from [10.174.177.2] (10.174.177.2) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Fri, 22 Jan 2021 16:27:24 +0800 Subject: Re: [PATCH] mm: Fix potential pte_unmap_unlock pte error From: Miaohe Lin To: Andrew Morton CC: , , , , , Andi Kleen References: <20210109080118.20885-1-linmiaohe@huawei.com> <20210110171443.GC1914459@tassilo.jf.intel.com> <530deddf-705e-045d-f7c6-521531dced71@huawei.com> Message-ID: <2c691a87-42fd-63f6-6d7a-136be6572fab@huawei.com> Date: Fri, 22 Jan 2021 16:27:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <530deddf-705e-045d-f7c6-521531dced71@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.2] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew: On 2021/1/14 10:51, Miaohe Lin wrote: > Hi: > On 2021/1/11 1:14, Andi Kleen wrote: >> On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: >>> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged >>> high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, >>> we would break the loop with pte unchanged. Then the wrong pte - 1 would >>> be passed to pte_unmap_unlock. >> >> Thanks. >> >> While the fix is correct, I'm not sure if it actually is a real bug. Is there >> any architecture that would do something else than unlocking the underlying >> page? If it's just the underlying page then it should be always the same >> page, so no bug. >> > > It's just a theoretical issue via code inspection. Should I send a new one without Cc statle or just drop this patch? Thanks. > >> That said of course the change is the right thing for main line, but probably doesn't >> need to be backported. >> > > So it should not be backported. Should I resend a patch or Andrew would kindly do this? > >> -Andi >> . >> > > Many thanks for review and reply. >