On Wed, 2022-11-02 at 11:13 +0100, Christophe Leroy wrote:
> 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 i
On Wed, 2022-11-02 at 09:43 +, 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.
>
> Wh
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 veri
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
It occurred to me that we don't require holding a lock when patching
text. Many use cases do hold text_mutex, but it's not required, so it's
possible for this warning to show false positives.
If we do want text_mutex be held, then lockdep_assert_held(&text_mutex)
ought to be added too.
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.
Signed-off-by: Benjamin Gray
---
arch/powerpc/lib/code-patching.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/pow
