Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2515138imm; Thu, 7 Jun 2018 11:59:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKSF7c34JggI0hM9gAcAyW4cAcluaGJj0e1Q3tGlasCdW1Firj7NuOZgD7tSkuJhdYff9wU X-Received: by 2002:a17:902:28ab:: with SMTP id f40-v6mr3236753plb.208.1528397946510; Thu, 07 Jun 2018 11:59:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528397946; cv=none; d=google.com; s=arc-20160816; b=TWQVmQmszoUmloeKyP91tWRqN8Oe4tzo5yh7D5XrML8d8RozPyaYAo0lOlvylWWgz5 c35+AP8Xi1Ql/Z02LkDIq+4unvYdg7JClp5Z9WqIJpZ8URRuffpICdoVWoQE96MEWwRO 6JAcQVnCf2OsErmqM8ruJuntkvcnR/IGFEL3NoY6/3pY0HpfmIkG+x7J2iiTUi5c7bLd 3wog3UQbkD0LxCw8jDeGg/D0s7lYoaqvEtqQo46VC4G2mPje3aE7nbeNhxsZznr1ammV N4aZtmBsRQQdDVCpta/+c2pYvbzYd+G58MWlEAPpDfT+CNvgwiTc9c4GZyPGMK/NSiXQ ox3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=YzZMET5ITA4C5FM/Jlp0Cq66m2LLOOU87w3BEMwQ7lA=; b=aBeAHM9M6RhDm3zwOhE6SgHWBWrR1uI8xuOhoaINA8OEzZegK98kiDMhHG3QeeTarm Fxk6QwrRzSk9vmXi09GHPWaXEm+KuTv2dFYMNOlVaNGa7M1RTsSUJwTKqmecyrL3rRq1 E+5MwbS6VI5qzQHDfFO/T0zMDouT44SukEKZRt0+BahpyA2YvNrtr4U+4rawizrUO2Ew JMje+dOti3kMyPgIaiHFILDV+26YiurRopRGCdwHm1a5j8pzNWFkmcwoXNuhPKSey2B3 tQvsIEb5h4bYTY2ZNk3gEXXY1/3HfEG44mbPnhr/yZIM9TTLnd2mkq4xVW0qK4qjOdir 64tQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=jQnaZWKL; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s4-v6si28688513pgc.634.2018.06.07.11.58.52; Thu, 07 Jun 2018 11:59: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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=jQnaZWKL; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753747AbeFGQYT (ORCPT + 99 others); Thu, 7 Jun 2018 12:24:19 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35220 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753510AbeFGQYR (ORCPT ); Thu, 7 Jun 2018 12:24:17 -0400 Received: by mail-wr0-f193.google.com with SMTP id l10-v6so10495361wrn.2 for ; Thu, 07 Jun 2018 09:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YzZMET5ITA4C5FM/Jlp0Cq66m2LLOOU87w3BEMwQ7lA=; b=jQnaZWKLkn4LVU+VAIZxhcbFqtb6eH1oH6Knpt31ma5bwJWcILnvN1N5Zrbw5bN2jd HHDDI402uLH0PR/91qydpHRUWkGobfWWI+VJlnRgJEvFAuuThe5BFu+Xr9/OFq5h5IHi 3Rv1E0PX7C0bzSp89Uhe0cv3yrcRGvWdwfaYLEG6J1rzFJJT/Rx4BfOhGJdkAbGFTwez iW3dk1M0iwfAYwdQHrn/y3ixzeq299m4sY99ZRP6V5lL9Ejky+cFC98mo2lMuu7v5eqd qwIRoJ7FPKFHHWvXus/oGa1m/TpHWKnmFbxnwhoKB20UyYSmut7ICB+P63OxSCjD9aVA 73Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YzZMET5ITA4C5FM/Jlp0Cq66m2LLOOU87w3BEMwQ7lA=; b=GsYbWXGUnlzsfA+Mx6+Q6bfQPklWs9MPeMTAMj/1oFtVGNM2NI1meOYqBh3bh8Pmrr Ye9KK5idetaEsFJtftjCCbKPvNGqZW76qJqD1OYKgaUkTov9xJZkhID+lLt0hzuz+2LS DkKomG9oht/GbmiJ5J6V7LdHk3SrQnlAZsVvPcbw6w3wH+DjFT1DyO0GU0GyXJFgGt0b JzsTt2A8fyOs7zWq/A+u/zsEKDVgkYBrzmNBdj64QymEVyRk7EhYeWr/D4gnIlAFVqm1 Dy8tWMemJhT0AZU9iiBasoJmWGMSZtjeFVLDUwVEa57opwkQde/8ssabDYFYky3YhhNx kLFQ== X-Gm-Message-State: APt69E3X3Y1Ulb/4ykqmZFUsSmPR3cFtBjldZjvhKsPu90KcgtsThSvi wskEq6abxg0T5yK/0lQUyQ60oR5TI0Ec1ISDjn2TpQ== X-Received: by 2002:adf:b445:: with SMTP id v5-v6mr2210625wrd.67.1528388655645; Thu, 07 Jun 2018 09:24:15 -0700 (PDT) MIME-Version: 1.0 References: <20180607143705.3531-1-yu-cheng.yu@intel.com> <20180607143705.3531-7-yu-cheng.yu@intel.com> In-Reply-To: <20180607143705.3531-7-yu-cheng.yu@intel.com> From: Andy Lutomirski Date: Thu, 7 Jun 2018 09:24:03 -0700 Message-ID: Subject: Re: [PATCH 6/9] x86/mm: Introduce ptep_set_wrprotect_flush and related functions To: Yu-cheng Yu Cc: LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "H. J. Lu" , "Shanbhogue, Vedvyas" , "Ravi V. Shankar" , Dave Hansen , Jonathan Corbet , Oleg Nesterov , Arnd Bergmann , mike.kravetz@oracle.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 7, 2018 at 7:40 AM Yu-cheng Yu wrote: > > The function ptep_set_wrprotect()/huge_ptep_set_wrprotect() is > used by copy_page_range()/copy_hugetlb_page_range() to copy > PTEs. > > On x86, when the shadow stack is enabled, only a shadow stack > PTE has the read-only and _PAGE_DIRTY_HW combination. Upon > making a dirty PTE read-only, we move its _PAGE_DIRTY_HW to > _PAGE_DIRTY_SW. > > When ptep_set_wrprotect() moves _PAGE_DIRTY_HW to _PAGE_DIRTY_SW, > if the PTE is writable and the mm is shared, another task could > race to set _PAGE_DIRTY_HW again. > > Introduce ptep_set_wrprotect_flush(), pmdp_set_wrprotect_flush(), > and huge_ptep_set_wrprotect_flush() to make sure this does not > happen. > This patch adds flushes where they didn't previously exist. > +static inline void ptep_set_wrprotect_flush(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep) > +{ > + bool rw; > + > + rw = test_and_clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte); > + if (IS_ENABLED(CONFIG_X86_INTEL_SHADOW_STACK_USER)) { > + struct mm_struct *mm = vma->vm_mm; > + pte_t pte; > + > + if (rw && (atomic_read(&mm->mm_users) > 1)) > + pte = ptep_clear_flush(vma, addr, ptep); Why are you clearing the pte? > -#define __HAVE_ARCH_PMDP_SET_WRPROTECT > -static inline void pmdp_set_wrprotect(struct mm_struct *mm, > - unsigned long addr, pmd_t *pmdp) > +#define __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT_FLUSH > +static inline void huge_ptep_set_wrprotect_flush(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep) > { > - clear_bit(_PAGE_BIT_RW, (unsigned long *)pmdp); > + ptep_set_wrprotect_flush(vma, addr, ptep); Maybe I'm just missing something, but you're changed the semantics of this function significantly.