From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Benjamin Gray <bgray@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: jniethe5@gmail.com, cmr@bluescreens.de, ajd@linux.ibm.com,
npiggin@gmail.com
Subject: Re: [PATCH v9 4/7] powerpc/code-patching: Verify instruction patch succeeded
Date: Wed, 2 Nov 2022 11:13:54 +0100 [thread overview]
Message-ID: <20a4382b-089a-442a-ad05-af893823c9dc@csgroup.eu> (raw)
In-Reply-To: <83e63455-95d8-88bf-82b2-c72bfe288fab@csgroup.eu>
Le 02/11/2022 à 10:43, Christophe Leroy a écrit :
>
>
> 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 ?
>
>>
>> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
>> ---
>> arch/powerpc/lib/code-patching.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/lib/code-patching.c
>> b/arch/powerpc/lib/code-patching.c
>> index 3b3b09d5d2e1..b0a12b2d5a9b 100644
>> --- a/arch/powerpc/lib/code-patching.c
>> +++ b/arch/powerpc/lib/code-patching.c
>> @@ -192,6 +192,8 @@ static int do_patch_instruction(u32 *addr,
>> ppc_inst_t instr)
>> err = __do_patch_instruction(addr, instr);
>> local_irq_restore(flags);
>> + WARN_ON(!err && !ppc_inst_equal(instr, ppc_inst_read(addr)));
>> +
Another point: you are doing the check outside of IRQ disabled section,
is that correct ? What if an interrupt changed it in-between ?
Or insn't that possible ? In that case what's the real purpose of
disabling IRQs here ?
>> return err;
>> }
>> #else /* !CONFIG_STRICT_KERNEL_RWX */
next prev parent reply other threads:[~2022-11-02 10:14 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 [this message]
2022-11-02 23:02 ` Benjamin Gray
2022-11-02 22:58 ` Benjamin Gray
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=20a4382b-089a-442a-ad05-af893823c9dc@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=ajd@linux.ibm.com \
--cc=bgray@linux.ibm.com \
--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).