From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
"keescook@chromium.org" <keescook@chromium.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [GIT PULL] x86/shstk for 6.4
Date: Sat, 6 May 2023 17:19:50 -0700 [thread overview]
Message-ID: <CAHk-=wiZjSu7c9sFYZb3q04108stgHff2wfbokGCCgW7riz+8Q@mail.gmail.com> (raw)
In-Reply-To: <ad5b44e17c1c17ebdc581169fec7e80f7ef2a4d4.camel@intel.com>
On Sat, May 6, 2023 at 5:10 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.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
next prev parent reply other threads:[~2023-05-07 0:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 21:21 [GIT PULL] x86/shstk for 6.4 Dave Hansen
2023-04-28 18:17 ` Linus Torvalds
2023-04-29 0:26 ` Edgecombe, Rick P
2023-04-29 0:40 ` Dave Hansen
2023-05-06 19:34 ` Linus Torvalds
2023-05-06 20:09 ` Linus Torvalds
2023-05-07 0:18 ` Edgecombe, Rick P
2023-05-07 0:38 ` Linus Torvalds
2023-05-07 15:57 ` Edgecombe, Rick P
2023-05-08 22:57 ` Dave Hansen
2023-05-08 23:31 ` Linus Torvalds
2023-05-08 23:47 ` Linus Torvalds
2023-05-12 17:34 ` Dave Hansen
2023-05-12 21:55 ` Linus Torvalds
2023-05-15 21:36 ` Dave Hansen
2023-05-15 21:37 ` Dave Hansen
2023-05-15 22:40 ` Linus Torvalds
2023-05-15 23:02 ` Linus Torvalds
2023-05-16 20:38 ` Linus Torvalds
2023-05-16 20:42 ` Dave Hansen
2023-05-09 0:07 ` Dave Hansen
2023-05-07 0:10 ` Edgecombe, Rick P
2023-05-07 0:19 ` Linus Torvalds [this message]
2023-05-07 16:24 ` Edgecombe, Rick P
2023-05-15 21:22 ` Deepak Gupta
2023-05-25 16:20 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wiZjSu7c9sFYZb3q04108stgHff2wfbokGCCgW7riz+8Q@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).