From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033196AbdD0ACu (ORCPT ); Wed, 26 Apr 2017 20:02:50 -0400 Received: from mail-dm3nam03on0073.outbound.protection.outlook.com ([104.47.41.73]:63282 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1033175AbdD0ACn (ORCPT ); Wed, 26 Apr 2017 20:02:43 -0400 From: Nadav Amit To: Andy Lutomirski , "x86@kernel.org" CC: "linux-kernel@vger.kernel.org" , "Borislav Petkov" , Rik van Riel , Dave Hansen , Michal Hocko , Sasha Levin , Andrew Morton Subject: Re: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly() Thread-Topic: [PATCH v3 1/4] x86/vm86/32: Switch to flush_tlb_mm_range() in mark_screen_rdonly() Thread-Index: AQHSuzZGppOzsSIHjkWnHSVwsMiFdqHX5aEAgAABxIA= Date: Thu, 27 Apr 2017 00:02:41 +0000 Message-ID: References: <791a644076fc3577ba7f7b7cafd643cc089baa7d.1492844372.git.luto@kernel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [208.91.1.34] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;BY2PR05MB2213;7:QAE1eDiu7uafOSRoO0QDlaRe488jdzUJp7qWyha4ybX1Wb7KH3Xk0XTppXVxjLjA/L1NJ4x5dTVuYU2dFBdwoOyecnb4bqLcSde4xjgpUPGZmi6ViiLpbOQ4IEi/6vl06HOQrqDT393qcU0EMNTYe7LpeB2q58PXozTk69wBdOVbcn9P5asgmweFkP09u/4XFIvVduIHHiCpuJEwhM4vXh7IMr/dzLfmcp3sm0mP/d62KQwS/dGm1CdrYenYPe5psuCDhEct/QP7B58QSQTQo+LecQD52wggRnLcgu7AfazN83gFkWbISrbIpwGqQaMux6uhrgMjrC8BF6e6fA++jQ==;20:a7FVbb8n0HRTcwKLNHVHSPUa0LoduinYqs22q0nqdAva61eck4qdYjkYGOtz6wdnlLOoW3Nm3zrevL4r40D6syj9GptYAn4oYM0KiFSBaNqUiqxvPnmb5taTmwQknY0z9X8/dOvI+Ur7M2CWWHOF3Vvb/Mj7o0dKH5NNzwS3CBU= x-ms-office365-filtering-correlation-id: bd7222aa-2596-4b7e-4c01-08d48d00b975 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075)(201703031133081);SRVR:BY2PR05MB2213; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(146099531331640)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148);SRVR:BY2PR05MB2213;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2213; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(377454003)(24454002)(82746002)(83716003)(102836003)(33656002)(6486002)(2501003)(6246003)(6506006)(6116002)(25786009)(77096006)(3846002)(99286003)(305945005)(8676002)(7736002)(81166006)(54906002)(189998001)(53936002)(53546009)(8936002)(6436002)(2900100001)(54356999)(229853002)(6512007)(50986999)(122556002)(66066001)(76176999)(2950100002)(86362001)(38730400002)(3660700001)(36756003)(3280700002)(5660300001)(4326008)(2906002);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR05MB2213;H:BY2PR05MB2215.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2EA3B502DB6FD14CA33612B8734D6214@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 00:02:41.6133 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2213 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3R04EIl017578 And besides, it looks as if the code was meant to flush the entire TLB in some cases (e.g., if pgd_none_or_clear_bad() is true). On 4/26/17, 4:56 PM, "Nadav Amit" wrote: It may be benign, but I don’t think that flushing the TLB without holding the ptl or the mmap_sem (for no apparent reason) is a good practice. On 4/22/17, 12:01 AM, "Andy Lutomirski" wrote: mark_screen_rdonly() is the last remaining caller of flush_tlb(). flush_tlb_mm_range() is potentially faster and isn't obsolete. Compile-tested only because I don't know whether software that uses this mechanism even exists. Cc: Rik van Riel Cc: Dave Hansen Cc: Nadav Amit Cc: Michal Hocko Cc: Sasha Levin Cc: Andrew Morton Signed-off-by: Andy Lutomirski --- arch/x86/kernel/vm86_32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c index 23ee89ce59a9..3eda76b3c835 100644 --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -193,7 +193,7 @@ static void mark_screen_rdonly(struct mm_struct *mm) pte_unmap_unlock(pte, ptl); out: up_write(&mm->mmap_sem); - flush_tlb(); + flush_tlb_mm_range(mm, 0xA0000, 0xA0000 + 32*PAGE_SIZE, 0UL); } -- 2.9.3