Hello,

These patches are related to a recently queued series [1] that fixes the
same bugs in normal code.  That series finishes with a patch that would
have exposed the BPF bugs, but luckily it won't get merged until v6.18.

I don't know enough about BPF to verify that it emits the correct code
now, so any pointers are welcome.

1: https://lore.kernel.org/linux-riscv/20250725165410.2896641-3-rkrcmar@ventanamicro.com/

Radim Krčmář (2):
  riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG
  riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id

 arch/riscv/net/bpf_jit_comp64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.50.0

Radim!

Radim Krčmář <rkrcmar@ventanamicro.com> writes:

> Hello,
>
> These patches are related to a recently queued series [1] that fixes the
> same bugs in normal code.  That series finishes with a patch that would
> have exposed the BPF bugs, but luckily it won't get merged until v6.18.
>
> I don't know enough about BPF to verify that it emits the correct code
> now, so any pointers are welcome.
>
> 1: https://lore.kernel.org/linux-riscv/20250725165410.2896641-3-rkrcmar@ventanamicro.com/

Apologies for the slow review!

For the series:

Acked-by: Björn Töpel <bjorn@kernel.org>
Tested-by: Björn Töpel <bjorn@rivosinc.com> # QEMU

Hi Radim,

On 8/12/25 11:02, Radim Krčmář wrote:
> Hello,
>
> These patches are related to a recently queued series [1] that fixes the
> same bugs in normal code.  That series finishes with a patch that would
> have exposed the BPF bugs, but luckily it won't get merged until v6.18.
>
> I don't know enough about BPF to verify that it emits the correct code
> now, so any pointers are welcome.
>
> 1: https://lore.kernel.org/linux-riscv/20250725165410.2896641-3-rkrcmar@ventanamicro.com/
>
> Radim Krčmář (2):
>    riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG
>    riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id
>
>   arch/riscv/net/bpf_jit_comp64.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>

Both patches look good so:

Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>

Since this only touches riscv and I have a bunch of fixes pending, I 
propose to take those patches through the riscv tree, I'll just wait for 
Björn to confirm it is correct.

@Radim: This is the third similar bug, did you check all assembly code 
(and bpf) to make sure we don't have anymore left or should I?

Thanks,

Alex

2025-08-12T13:37:16+02:00, Alexandre Ghiti <alex@ghiti.fr>:
> @Radim: This is the third similar bug, did you check all assembly code 
> (and bpf) to make sure we don't have anymore left or should I?

I looked at load/store instructions, including bpf, and focussed on
patterns where we access non-xlen sized data through an offset.

(Nothing else popped up, but I mostly used grep and cscope as I don't
 know of any semantic tool, so my confidence levels are low.)

Hi Radim,

On 8/12/25 15:09, Radim Krčmář wrote:
> 2025-08-12T13:37:16+02:00, Alexandre Ghiti <alex@ghiti.fr>:
>> @Radim: This is the third similar bug, did you check all assembly code
>> (and bpf) to make sure we don't have anymore left or should I?
> I looked at load/store instructions, including bpf, and focussed on
> patterns where we access non-xlen sized data through an offset.
>
> (Nothing else popped up, but I mostly used grep and cscope as I don't
>   know of any semantic tool, so my confidence levels are low.)


Ok thanks, I don't have any better idea than eye scrubbing so I'll take 
another look to improve our confidence. One good thing is that now I 
don't let them pass in reviews :)

Thanks for noticing this class of bugs!

Alex


>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv