2024-02-29 12:12:31

by Alexandre Ghiti

[permalink] [raw]
Subject: [PATCH v3 0/2] riscv: fix patching with IPI

patch 1 removes a useless memory barrier and patch 2 actually fixes the
issue with IPI in the patching code.

Changes in v3:
- Remove wrong cleanup as noted by Samuel
- Enhance comment about usage of release semantics as suggested by
Andrea
- Add RBs from Andrea

Changes in v2:
- Add patch 1 and then remove the memory barrier from patch 2 as
suggested by Andrea
- Convert atomic_inc into an atomic_inc with release semantics as
suggested by Andrea

Alexandre Ghiti (2):
riscv: Remove superfluous smp_mb()
riscv: Fix text patching when IPI are used

arch/riscv/include/asm/patch.h | 1 +
arch/riscv/kernel/ftrace.c | 44 ++++++++++++++++++++++++++++++----
arch/riscv/kernel/patch.c | 17 +++++++++----
3 files changed, 53 insertions(+), 9 deletions(-)

--
2.39.2



2024-02-29 12:13:12

by Alexandre Ghiti

[permalink] [raw]
Subject: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

For now, we use stop_machine() to patch the text and when we use IPIs for
remote icache flushes (which is emitted in patch_text_nosync()), the system
hangs.

So instead, make sure every CPU executes the stop_machine() patching
function and emit a local icache flush there.

Co-developed-by: Björn Töpel <[email protected]>
Signed-off-by: Björn Töpel <[email protected]>
Signed-off-by: Alexandre Ghiti <[email protected]>
Reviewed-by: Andrea Parri <[email protected]>
---
arch/riscv/include/asm/patch.h | 1 +
arch/riscv/kernel/ftrace.c | 44 ++++++++++++++++++++++++++++++----
arch/riscv/kernel/patch.c | 16 +++++++++----
3 files changed, 53 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/include/asm/patch.h b/arch/riscv/include/asm/patch.h
index e88b52d39eac..9f5d6e14c405 100644
--- a/arch/riscv/include/asm/patch.h
+++ b/arch/riscv/include/asm/patch.h
@@ -6,6 +6,7 @@
#ifndef _ASM_RISCV_PATCH_H
#define _ASM_RISCV_PATCH_H

+int patch_insn_write(void *addr, const void *insn, size_t len);
int patch_text_nosync(void *addr, const void *insns, size_t len);
int patch_text_set_nosync(void *addr, u8 c, size_t len);
int patch_text(void *addr, u32 *insns, int ninsns);
diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index f5aa24d9e1c1..4f4987a6d83d 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -8,6 +8,7 @@
#include <linux/ftrace.h>
#include <linux/uaccess.h>
#include <linux/memory.h>
+#include <linux/stop_machine.h>
#include <asm/cacheflush.h>
#include <asm/patch.h>

@@ -75,8 +76,7 @@ static int __ftrace_modify_call(unsigned long hook_pos, unsigned long target,
make_call_t0(hook_pos, target, call);

/* Replace the auipc-jalr pair at once. Return -EPERM on write error. */
- if (patch_text_nosync
- ((void *)hook_pos, enable ? call : nops, MCOUNT_INSN_SIZE))
+ if (patch_insn_write((void *)hook_pos, enable ? call : nops, MCOUNT_INSN_SIZE))
return -EPERM;

return 0;
@@ -88,7 +88,7 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)

make_call_t0(rec->ip, addr, call);

- if (patch_text_nosync((void *)rec->ip, call, MCOUNT_INSN_SIZE))
+ if (patch_insn_write((void *)rec->ip, call, MCOUNT_INSN_SIZE))
return -EPERM;

return 0;
@@ -99,7 +99,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace *rec,
{
unsigned int nops[2] = {NOP4, NOP4};

- if (patch_text_nosync((void *)rec->ip, nops, MCOUNT_INSN_SIZE))
+ if (patch_insn_write((void *)rec->ip, nops, MCOUNT_INSN_SIZE))
return -EPERM;

return 0;
@@ -134,6 +134,42 @@ int ftrace_update_ftrace_func(ftrace_func_t func)

return ret;
}
+
+struct ftrace_modify_param {
+ int command;
+ atomic_t cpu_count;
+};
+
+static int __ftrace_modify_code(void *data)
+{
+ struct ftrace_modify_param *param = data;
+
+ if (atomic_inc_return(&param->cpu_count) == num_online_cpus()) {
+ ftrace_modify_all_code(param->command);
+ /*
+ * Make sure the patching store is effective *before* we
+ * increment the counter which releases all waiting CPUs
+ * by using the release variant of atomic increment. The
+ * release pairs with the call to local_flush_icache_all()
+ * on the waiting CPU.
+ */
+ atomic_inc_return_release(&param->cpu_count);
+ } else {
+ while (atomic_read(&param->cpu_count) <= num_online_cpus())
+ cpu_relax();
+ }
+
+ local_flush_icache_all();
+
+ return 0;
+}
+
+void arch_ftrace_update_code(int command)
+{
+ struct ftrace_modify_param param = { command, ATOMIC_INIT(0) };
+
+ stop_machine(__ftrace_modify_code, &param, cpu_online_mask);
+}
#endif

#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 0b5c16dfe3f4..9a1bce1adf5a 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -188,7 +188,7 @@ int patch_text_set_nosync(void *addr, u8 c, size_t len)
}
NOKPROBE_SYMBOL(patch_text_set_nosync);

-static int patch_insn_write(void *addr, const void *insn, size_t len)
+int patch_insn_write(void *addr, const void *insn, size_t len)
{
size_t patched = 0;
size_t size;
@@ -232,15 +232,23 @@ static int patch_text_cb(void *data)
if (atomic_inc_return(&patch->cpu_count) == num_online_cpus()) {
for (i = 0; ret == 0 && i < patch->ninsns; i++) {
len = GET_INSN_LENGTH(patch->insns[i]);
- ret = patch_text_nosync(patch->addr + i * len,
- &patch->insns[i], len);
+ ret = patch_insn_write(patch->addr + i * len, &patch->insns[i], len);
}
- atomic_inc(&patch->cpu_count);
+ /*
+ * Make sure the patching store is effective *before* we
+ * increment the counter which releases all waiting CPUs
+ * by using the release variant of atomic increment. The
+ * release pairs with the call to local_flush_icache_all()
+ * on the waiting CPU.
+ */
+ atomic_inc_return_release(&patch->cpu_count);
} else {
while (atomic_read(&patch->cpu_count) <= num_online_cpus())
cpu_relax();
}

+ local_flush_icache_all();
+
return ret;
}
NOKPROBE_SYMBOL(patch_text_cb);
--
2.39.2


2024-03-04 19:27:16

by Conor Dooley

[permalink] [raw]
Subject: Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
> For now, we use stop_machine() to patch the text and when we use IPIs for
> remote icache flushes (which is emitted in patch_text_nosync()), the system
> hangs.
>
> So instead, make sure every CPU executes the stop_machine() patching
> function and emit a local icache flush there.
>
> Co-developed-by: Bj?rn T?pel <[email protected]>
> Signed-off-by: Bj?rn T?pel <[email protected]>
> Signed-off-by: Alexandre Ghiti <[email protected]>
> Reviewed-by: Andrea Parri <[email protected]>

What commit does this fix?


Attachments:
(No filename) (610.00 B)
signature.asc (235.00 B)
Download all attachments

2024-03-04 20:24:20

by Björn Töpel

[permalink] [raw]
Subject: Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

Conor Dooley <[email protected]> writes:

> On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
>> For now, we use stop_machine() to patch the text and when we use IPIs for
>> remote icache flushes (which is emitted in patch_text_nosync()), the system
>> hangs.
>>
>> So instead, make sure every CPU executes the stop_machine() patching
>> function and emit a local icache flush there.
>>
>> Co-developed-by: Björn Töpel <[email protected]>
>> Signed-off-by: Björn Töpel <[email protected]>
>> Signed-off-by: Alexandre Ghiti <[email protected]>
>> Reviewed-by: Andrea Parri <[email protected]>
>
> What commit does this fix?

Hmm. The bug is exposed when the AIA IPI are introduced, and used
(instead of the firmware-based).

I'm not sure this is something we'd like backported, but rather a
prerequisite to AIA.

@Anup @Alex WDYT?

2024-03-05 03:03:56

by Anup Patel

[permalink] [raw]
Subject: Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel <[email protected]> wrote:
>
> Conor Dooley <[email protected]> writes:
>
> > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
> >> For now, we use stop_machine() to patch the text and when we use IPIs for
> >> remote icache flushes (which is emitted in patch_text_nosync()), the system
> >> hangs.
> >>
> >> So instead, make sure every CPU executes the stop_machine() patching
> >> function and emit a local icache flush there.
> >>
> >> Co-developed-by: Björn Töpel <[email protected]>
> >> Signed-off-by: Björn Töpel <[email protected]>
> >> Signed-off-by: Alexandre Ghiti <[email protected]>
> >> Reviewed-by: Andrea Parri <[email protected]>
> >
> > What commit does this fix?
>
> Hmm. The bug is exposed when the AIA IPI are introduced, and used
> (instead of the firmware-based).
>
> I'm not sure this is something we'd like backported, but rather a
> prerequisite to AIA.
>
> @Anup @Alex WDYT?
>

The current text patching never considered IPIs being injected
directly in S-mode from hart to another so we are seeing this
issue now with AIA IPIs.

We certainly don't need to backport this fix since it's more
of a preparatory fix for AIA IPIs.

Regards,
Anup

2024-03-05 08:01:06

by Conor Dooley

[permalink] [raw]
Subject: Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

On Tue, Mar 05, 2024 at 08:33:30AM +0530, Anup Patel wrote:
> On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel <[email protected]> wrote:
> >
> > Conor Dooley <[email protected]> writes:
> >
> > > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
> > >> For now, we use stop_machine() to patch the text and when we use IPIs for
> > >> remote icache flushes (which is emitted in patch_text_nosync()), the system
> > >> hangs.
> > >>
> > >> So instead, make sure every CPU executes the stop_machine() patching
> > >> function and emit a local icache flush there.
> > >>
> > >> Co-developed-by: Björn Töpel <[email protected]>
> > >> Signed-off-by: Björn Töpel <[email protected]>
> > >> Signed-off-by: Alexandre Ghiti <[email protected]>
> > >> Reviewed-by: Andrea Parri <[email protected]>
> > >
> > > What commit does this fix?
> >
> > Hmm. The bug is exposed when the AIA IPI are introduced, and used
> > (instead of the firmware-based).
> >
> > I'm not sure this is something we'd like backported, but rather a
> > prerequisite to AIA.
> >
> > @Anup @Alex WDYT?
> >
>
> The current text patching never considered IPIs being injected
> directly in S-mode from hart to another so we are seeing this
> issue now with AIA IPIs.
>
> We certainly don't need to backport this fix since it's more
> of a preparatory fix for AIA IPIs.

Whether or not this is backportable, if it fixes a bug, it should get
a Fixes: tag for the commit that it fixes. Fixes: isn't "the backport"
tag, cc: stable is.


Attachments:
(No filename) (1.52 kB)
signature.asc (235.00 B)
Download all attachments

2024-03-05 08:21:52

by Björn Töpel

[permalink] [raw]
Subject: Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

Conor Dooley <[email protected]> writes:

> On Tue, Mar 05, 2024 at 08:33:30AM +0530, Anup Patel wrote:
>> On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel <[email protected]> wrote:
>> >
>> > Conor Dooley <[email protected]> writes:
>> >
>> > > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:
>> > >> For now, we use stop_machine() to patch the text and when we use IPIs for
>> > >> remote icache flushes (which is emitted in patch_text_nosync()), the system
>> > >> hangs.
>> > >>
>> > >> So instead, make sure every CPU executes the stop_machine() patching
>> > >> function and emit a local icache flush there.
>> > >>
>> > >> Co-developed-by: Björn Töpel <[email protected]>
>> > >> Signed-off-by: Björn Töpel <[email protected]>
>> > >> Signed-off-by: Alexandre Ghiti <[email protected]>
>> > >> Reviewed-by: Andrea Parri <[email protected]>
>> > >
>> > > What commit does this fix?
>> >
>> > Hmm. The bug is exposed when the AIA IPI are introduced, and used
>> > (instead of the firmware-based).
>> >
>> > I'm not sure this is something we'd like backported, but rather a
>> > prerequisite to AIA.
>> >
>> > @Anup @Alex WDYT?
>> >
>>
>> The current text patching never considered IPIs being injected
>> directly in S-mode from hart to another so we are seeing this
>> issue now with AIA IPIs.
>>
>> We certainly don't need to backport this fix since it's more
>> of a preparatory fix for AIA IPIs.
>
> Whether or not this is backportable, if it fixes a bug, it should get
> a Fixes: tag for the commit that it fixes. Fixes: isn't "the backport"
> tag, cc: stable is.

I guess the question is if this *is* a fix, or rather a change required
for AIA (not a fix).