[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiZjSu7c9sFYZb3q04108stgHff2wfbokGCCgW7riz+8Q@mail.gmail.com>
Date: Sat, 6 May 2023 17:19:50 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "Hansen, Dave" <dave.hansen@...el.com>,
"keescook@...omium.org" <keescook@...omium.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [GIT PULL] x86/shstk for 6.4
On Sat, May 6, 2023 at 5:10 PM Edgecombe, Rick P
<rick.p.edgecombe@...el.com> wrote:
>
> I think I did try something like your suggestion during development. My
> (maybe misguided) concern was that pte_mkwrite_kernel() might not make
> semantic sense for all architectures since not all architectures were
> using pte_mkwrite() on kernel memory.
Yeah, I agree, it's not a great name.
How about just calling it "pte_mkwrite_novma()" instead?
That makes semantic sense for all architectures: it's basically saying
"this is the version of mkwrite that doesn't take a vma".
And then it also makes complete sense to say
#define pte_mkwrite(vma,pte) pte_mkwrite_novma(pte)
(or the "inline function" version of the same just to make sure the
'vma' argument is evaluated) on the architectures that really don't
care about the vma.
And it also makes sense for the x86 kernel use that doesn't have a vma...
So I think "novma" is more closely related to what the semantics
actually are, and the "kernel" thing is just a "on x86-64, we have
this special case where we don't have vma's and don't worry about
losing the dirty bit".
Hmm?
Linus
Powered by blists - more mailing lists