[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6d6e3fec807bfada22968bbaa07538c04b0b491.camel@intel.com>
Date: Fri, 14 Oct 2022 18:06:06 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "peterz@...radead.org" <peterz@...radead.org>
CC: "bsingharora@...il.com" <bsingharora@...il.com>,
"hpa@...or.com" <hpa@...or.com>,
"Syromiatnikov, Eugene" <esyr@...hat.com>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"Eranian, Stephane" <eranian@...gle.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"nadav.amit@...il.com" <nadav.amit@...il.com>,
"jannh@...gle.com" <jannh@...gle.com>,
"dethoma@...rosoft.com" <dethoma@...rosoft.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"kcc@...gle.com" <kcc@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
"oleg@...hat.com" <oleg@...hat.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"Yang, Weijiang" <weijiang.yang@...el.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"pavel@....cz" <pavel@....cz>, "arnd@...db.de" <arnd@...db.de>,
"Moreira, Joao" <joao.moreira@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
"john.allen@....com" <john.allen@....com>,
"rppt@...nel.org" <rppt@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"gorcunov@...il.com" <gorcunov@...il.com>
Subject: Re: [PATCH v2 10/39] x86/mm: Introduce _PAGE_COW
On Fri, 2022-10-14 at 11:42 +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2022 at 03:29:07PM -0700, Rick Edgecombe wrote:
> > @@ -300,6 +324,44 @@ static inline pte_t pte_clear_flags(pte_t pte,
> > pteval_t clear)
> > return native_make_pte(v & ~clear);
> > }
> >
> > +/*
> > + * Normally the Dirty bit is used to denote COW memory on x86. But
>
> This is misleading; this isn't an x86 specific thing. The core-mm
> code
> does this.
Well pte_mkdirty() does map to other HW bits on different
architectures. But yea, it's confusing.
Hmm, is this comment a bit stale either way now though? In the past it
was probably more accurate to say core MM code used it to "detect"
cowed memory. But the GUP pte_dirty() check was changed recently:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5535be3099717646781ce1540cf725965d680e7b
I don't think any code is looking specifically for COWed memory using
the PTE dirty bit anymore, it just happens to coincide with it. Double
checking my understanding...
Maybe this would be more accurate?
/*
* Normally COW memory can result in Dirty=1,Write=0 PTEs. But in the
* case of X86_FEATURE_SHSTK, the software COW bit is used, since the
* Dirty=1,Write=0 will result in the memory being treated as shaodw
* stack by the HW. So when creating COW memory, a software bit is used
* _PAGE_BIT_COW. The following functions pte_mkcow() and
* pte_clear_cow() take a PTE marked conventially COW (Dirty=1) and
* transition it to the shadow stack compatible version of COW (Cow=1).
*/
Powered by blists - more mailing lists