Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2247811imm; Tue, 10 Jul 2018 16:25:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpegzjjuB9ig/hTxx7pnE5fiyWFqvfGLd7HXN15W//g5B2FnIeUIGPoGY/W9PRGvGXswcIYO X-Received: by 2002:a62:283:: with SMTP id 125-v6mr27632341pfc.51.1531265106384; Tue, 10 Jul 2018 16:25:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531265106; cv=none; d=google.com; s=arc-20160816; b=UbScrO5Vbl+JqUObsBt/cgpHT3ARMZcbS2D0XDtCjjo/3HPMWkhl3q6Hx+cDY7Lp2L Tz/2B6wxq6R/nSnwujJifF57JdvMNB2AB3EHTDS33CimqPYKTYZcZXj+a8vREKjvGGfE 0h7DN2m+B2qbX9ni9JY3WUfkofCbkSUo9pbPvz1g01Xme0qzkuAt9+kr6Lw5kPzdlour zawv7awCHhUNvposh2e4Mw8zmardjDsptPPzXT1QLY4T7MeTXgOEPHoydKUX4JDxRrww CCchfm6VOMY7LjZCRSvp801Pbxbm40LyhjhBSnTYTq+zzVPuYlHXnS5/6zzevsUiP14H VVbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=LJ2e2wvx4ZWrvmGIqC2g8qcfq+ffiY4DZ10hg02y3XA=; b=uvDogG9IKc5xUThSsT2UAa/piwh52WBa+kzmEFESN7RIbCBV27xIaFZbbpu2o/UEgN 6l9NgQqqPQYLef1HgbyhqVAFlDS0bzWYaDrPlcUP1kPPONfL7EmG7Dg1XSxhRe9NA0hM SJQFYbVUYHJWEr0wFZTPBe26od7mFHJmcCEaERYzoi0uHUJ+IlV2H0I6i1H/cvcvjXSc 1Ivj4RzUaKksndOx9N6gB+dcYPe69/GZPVMvlpEnvjNuJ1d9BudJZseKk0YqNkI09RfK hW+xnGnW42DFvZce0Z1/N/OLciRopWJDb7fDdVvr6yUa5y4E5TeB2fth49UWta6LplLm sr8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d6PRvZZ4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q16-v6si5697215pgg.619.2018.07.10.16.24.51; Tue, 10 Jul 2018 16:25:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=d6PRvZZ4; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732380AbeGJXYf (ORCPT + 99 others); Tue, 10 Jul 2018 19:24:35 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:39018 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732272AbeGJXYf (ORCPT ); Tue, 10 Jul 2018 19:24:35 -0400 Received: by mail-wm0-f68.google.com with SMTP id h20-v6so622399wmb.4; Tue, 10 Jul 2018 16:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LJ2e2wvx4ZWrvmGIqC2g8qcfq+ffiY4DZ10hg02y3XA=; b=d6PRvZZ4bKMwF9Gup4YZIbDw7Y9cJkafZ9olcOgK5KA4cxqGYIrGgoKqFAC1vnFwIn N7X/Qx+/Mhnk17OZ67oW1o0bwGYM+hTVrN0q5KzwodTwtgzFU5tFXCBOBX+eKD7efjdc LPt47cB+m2x7Dk+QnjgD/r39yZ2qnZATFwSUMgAqaZu2n6sEGpvVP39v/5WOzpuSim4/ 3fDEdvQXerNeyC22jdk4X1KDZ5pMFYfDlbMi/1idALPl1iwNUGC3Go4RAFAZj5zH0Z87 LpYGKCa6Am/7KOjEOJVoZek9pZESCf58CSa66wWK3GRLn1n700OPW8+dCTtF7aixCeFf jPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LJ2e2wvx4ZWrvmGIqC2g8qcfq+ffiY4DZ10hg02y3XA=; b=CONNpsmdoxqfMYWsoz7s2CymH6ioCYVSCewFIjKFtS6Ljziy2Qkr6bPN9iM92YuXRt Ss+AhiUBOQHZeGk5lvL4VrgCI6r1083vm83vchq7LXaKX4PacHsPi32EivFYkOfiDyPO S2Fl5oX4yizaOk2lbH6jO1Ck7KfC0Gp970T3AKXkkxJAvOnoZpkZ+/mJLlYo0shYOg4G zP3GU4lj9STZveUoveic+uOhuiQ2Iw1bcgE/aNPi05XqSKotm6PxghYj1WJeaIYQJp10 tcM6mI5i94q50TSD8R7YliizWufzZDWyvYztAt5QaSrbmDBOKBqVi4BKV0TaftNdyLkN TV8Q== X-Gm-Message-State: APt69E0jRNnI9ifvjHHYanO2ZRQAe3PZ+xMt8HlSQRBhsHxbhIITu4dA oWAr7TwkJRMVUjO0OQ9NFiM= X-Received: by 2002:a1c:700a:: with SMTP id l10-v6mr12981311wmc.90.1531264991130; Tue, 10 Jul 2018 16:23:11 -0700 (PDT) Received: from [10.10.40.181] ([38.97.127.241]) by smtp.gmail.com with ESMTPSA id g125-v6sm405858wmf.16.2018.07.10.16.23.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 16:23:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: [RFC PATCH v2 11/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW From: Nadav Amit In-Reply-To: Date: Tue, 10 Jul 2018 19:23:04 -0400 Cc: X86 ML , Linux Kernel Mailing List Content-Transfer-Encoding: 7bit Message-Id: References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-12-yu-cheng.yu@intel.com> To: Dave Hansen , Yu-cheng Yu , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Oleg Nesterov , Pavel Machek , Peter Zijlstra , "Ravi V. Shankar" , Vedvyas Shanbhogue X-Mailer: Apple Mail (2.3445.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org at 6:44 PM, Dave Hansen wrote: > On 07/10/2018 03:26 PM, Yu-cheng Yu wrote: >> + /* >> + * On platforms before CET, other threads could race to >> + * create a RO and _PAGE_DIRTY_HW PMD again. However, >> + * on CET platforms, this is safe without a TLB flush. >> + */ > > If I didn't work for Intel, I'd wonder what the heck CET is and what the > heck it has to do with _PAGE_DIRTY_HW. I think we need a better comment > than this. How about: > > Some processors can _start_ a write, but end up seeing > a read-only PTE by the time they get to getting the > Dirty bit. In this case, they will set the Dirty bit, > leaving a read-only, Dirty PTE which looks like a Shadow > Stack PTE. > > However, this behavior has been improved and will *not* occur on > processors supporting Shadow Stacks. Without this guarantee, a > transition to a non-present PTE and flush the TLB would be > needed. Interesting. Does that regard the knights landing bug or something more general? Will the write succeed or trigger a page-fault in this case? [ I know it is not related to the patch, but I would appreciate if you share your knowledge ] Regards, Nadav