From: Benjamin Gray <bgray@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "jniethe5@gmail.com" <jniethe5@gmail.com>,
"cmr@bluescreens.de" <cmr@bluescreens.de>,
"ajd@linux.ibm.com" <ajd@linux.ibm.com>,
"npiggin@gmail.com" <npiggin@gmail.com>
Subject: Re: [PATCH v9 4/7] powerpc/code-patching: Verify instruction patch succeeded
Date: Thu, 03 Nov 2022 09:58:28 +1100 [thread overview]
Message-ID: <b2c86cdb980d96cb10a558baafdb5e94062852cf.camel@linux.ibm.com> (raw)
In-Reply-To: <83e63455-95d8-88bf-82b2-c72bfe288fab@csgroup.eu>
On Wed, 2022-11-02 at 09:43 +0000, Christophe Leroy wrote:
> Le 25/10/2022 à 06:44, Benjamin Gray a écrit :
> > Verifies that if the instruction patching did not return an error
> > then
> > the value stored at the given address to patch is now equal to the
> > instruction we patched it to.
>
> Why do we need that verification ? Until now it wasn't necessary, can
> you describe a failure that occurs because we don't have this
> verification ? Or is that until now it was reliable but the new
> method
> you are adding will not be as reliable as before ?
>
> What worries me with that new verification is that you are reading a
> memory address with is mostly only used for code execution. That
> means:
> - You will almost always take a DATA TLB Miss, hence performance
> impact.
> - If one day we want Exec-only text mappings, it will become
> problematic.
>
> So really the question is, is that patch really required ?
It's required as much as any sanity check in the kernel. I agree
running it all the time is not great though, I would prefer to make it
a debug-only check. I've seen VM_WARN_ON be used for this purpose I
think? It's especially useful now with churn on the code-patching code.
I don't expect the new method to be unreliable—I wouldn't be submitting
it if I did—but I'd much prefer to have an obvious tell if it does turn
out so.
But the above is all moot because we allow parallel patching, so the
check is just plain incorrect.
next prev parent reply other threads:[~2022-11-02 22:59 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 4:44 [PATCH v9 0/7] Use per-CPU temporary mappings for patching on Radix MMU Benjamin Gray
2022-10-25 4:44 ` [PATCH v9 1/7] powerpc: Allow clearing and restoring registers independent of saved breakpoint state Benjamin Gray
2022-10-25 4:44 ` [PATCH v9 2/7] powerpc/code-patching: Handle RWX patching initialisation error Benjamin Gray
2022-11-02 9:36 ` Christophe Leroy
2022-11-02 22:37 ` Benjamin Gray
2022-10-25 4:44 ` [PATCH v9 3/7] powerpc/code-patching: Use WARN_ON and fix check in poking_init Benjamin Gray
2022-11-02 9:38 ` Christophe Leroy
2022-11-02 22:42 ` Benjamin Gray
2022-10-25 4:44 ` [PATCH v9 4/7] powerpc/code-patching: Verify instruction patch succeeded Benjamin Gray
2022-10-26 0:47 ` Benjamin Gray
2022-11-02 9:43 ` Christophe Leroy
2022-11-02 10:13 ` Christophe Leroy
2022-11-02 23:02 ` Benjamin Gray
2022-11-02 22:58 ` Benjamin Gray [this message]
2022-10-25 4:44 ` [PATCH v9 5/7] powerpc/tlb: Add local flush for page given mm_struct and psize Benjamin Gray
2022-11-02 9:56 ` Christophe Leroy
2022-11-03 0:39 ` Benjamin Gray
2022-11-03 0:45 ` Andrew Donnellan
2022-11-07 6:58 ` Benjamin Gray
2022-11-07 12:28 ` Nicholas Piggin
2022-10-25 4:44 ` [PATCH v9 6/7] powerpc/code-patching: Use temporary mm for Radix MMU Benjamin Gray
2022-11-02 10:11 ` Christophe Leroy
2022-11-03 3:10 ` Benjamin Gray
2022-11-08 5:16 ` Benjamin Gray
2022-10-25 4:44 ` [PATCH v9 7/7] powerpc/code-patching: Consolidate and cache per-cpu patching context Benjamin Gray
2022-11-02 10:17 ` Christophe Leroy
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=b2c86cdb980d96cb10a558baafdb5e94062852cf.camel@linux.ibm.com \
--to=bgray@linux.ibm.com \
--cc=ajd@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=cmr@bluescreens.de \
--cc=jniethe5@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
/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).