<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch, branch v6.12.53</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.53</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.53'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-10-15T10:00:25+00:00</updated>
<entry>
<title>arm64: dts: qcom: qcm2290: Disable USB SS bus instances in park mode</title>
<updated>2025-10-15T10:00:25+00:00</updated>
<author>
<name>Konrad Dybcio</name>
<email>konrad.dybcio@oss.qualcomm.com</email>
</author>
<published>2025-07-08T10:28:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cde10a9473b028c4eebd92f2862eb740bb859edc'/>
<id>urn:sha1:cde10a9473b028c4eebd92f2862eb740bb859edc</id>
<content type='text'>
commit 27f94b71532203b079537180924023a5f636fca1 upstream.

2290 was found in the field to also require this quirk, as long &amp;
high-bandwidth workloads (e.g. USB ethernet) are consistently able to
crash the controller otherwise.

The same change has been made for a number of SoCs in [1], but QCM2290
somehow escaped the list (even though the very closely related SM6115
was there).

Upon a controller crash, the log would read:

xhci-hcd.12.auto: xHCI host not responding to stop endpoint command
xhci-hcd.12.auto: xHCI host controller not responding, assume dead
xhci-hcd.12.auto: HC died; cleaning up

Add snps,parkmode-disable-ss-quirk to the DWC3 instance in order to
prevent the aforementioned breakage.

[1] https://lore.kernel.org/all/20240704152848.3380602-1-quic_kriskura@quicinc.com/

Cc: stable@vger.kernel.org
Reported-by: Rob Clark &lt;robin.clark@oss.qualcomm.com&gt;
Fixes: a64a0192b70c ("arm64: dts: qcom: Add initial QCM2290 device tree")
Signed-off-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20250708-topic-2290_usb-v1-1-661e70a63339@oss.qualcomm.com
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid</title>
<updated>2025-10-15T10:00:22+00:00</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2025-08-05T19:05:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f994e9c790ce97d3cf01af4d0a1b9add0c955aee'/>
<id>urn:sha1:f994e9c790ce97d3cf01af4d0a1b9add0c955aee</id>
<content type='text'>
commit 0910dd7c9ad45a2605c45fd2bf3d1bcac087687c upstream.

Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP
isn't valid, e.g. because KVM is running with nrips=false.  SVM must
decode and emulate to skip the instruction if the CPU doesn't provide the
next RIP, and getting the instruction bytes to decode requires reading
guest memory.  Reading guest memory through the emulator can fault, i.e.
can sleep, which is disallowed since the fastpath handlers run with IRQs
disabled.

 BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106
 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu
 preempt_count: 1, expected: 0
 INFO: lockdep is turned off.
 irq event stamp: 30580
 hardirqs last  enabled at (30579): [&lt;ffffffffc08b2527&gt;] vcpu_run+0x1787/0x1db0 [kvm]
 hardirqs last disabled at (30580): [&lt;ffffffffb4f62e32&gt;] __schedule+0x1e2/0xed0
 softirqs last  enabled at (30570): [&lt;ffffffffb4247a64&gt;] fpu_swap_kvm_fpstate+0x44/0x210
 softirqs last disabled at (30568): [&lt;ffffffffb4247a64&gt;] fpu_swap_kvm_fpstate+0x44/0x210
 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G     U              6.16.0-smp--e6c618b51cfe-sleep #782 NONE
 Tainted: [U]=USER
 Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025
 Call Trace:
  &lt;TASK&gt;
  dump_stack_lvl+0x7d/0xb0
  __might_resched+0x271/0x290
  __might_fault+0x28/0x80
  kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]
  kvm_fetch_guest_virt+0x92/0xc0 [kvm]
  __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]
  x86_decode_insn+0xd1/0x1010 [kvm]
  x86_emulate_instruction+0x105/0x810 [kvm]
  __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]
  handle_fastpath_invd+0xc4/0x1a0 [kvm]
  vcpu_run+0x11a1/0x1db0 [kvm]
  kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]
  kvm_vcpu_ioctl+0x578/0x6a0 [kvm]
  __se_sys_ioctl+0x6d/0xb0
  do_syscall_64+0x8a/0x2c0
  entry_SYSCALL_64_after_hwframe+0x4b/0x53
 RIP: 0033:0x7f479d57a94b
  &lt;/TASK&gt;

Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM:
Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with
different justification (KVM now grabs SRCU when skipping the instruction
for other reasons).

Fixes: b439eb8ab578 ("Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250805190526.1453366-2-seanjc@google.com
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>LoongArch: Automatically disable kaslr if boot from kexec_file</title>
<updated>2025-10-15T10:00:22+00:00</updated>
<author>
<name>Youling Tang</name>
<email>tangyouling@kylinos.cn</email>
</author>
<published>2025-10-02T14:39:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=987f2bd63ace72ccdee0e68d5d1924f4f121e16b'/>
<id>urn:sha1:987f2bd63ace72ccdee0e68d5d1924f4f121e16b</id>
<content type='text'>
commit c8168b4faf1d62cbb320a3e518ad31cdd567cb05 upstream.

Automatically disable kaslr when the kernel loads from kexec_file.

kexec_file loads the secondary kernel image to a non-linked address,
inherently providing KASLR-like randomization.

However, on LoongArch where System RAM may be non-contiguous, enabling
KASLR for the second kernel may relocate it to an invalid memory region
and cause a boot failure. Thus, we disable KASLR when "kexec_file" is
detected in the command line.

To ensure compatibility with older kernels loaded via kexec_file, this
patch should be backported to stable branches.

Cc: stable@vger.kernel.org
Signed-off-by: Youling Tang &lt;tangyouling@kylinos.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc: fix accurate exception reporting in copy_{from,to}_user for M7</title>
<updated>2025-10-15T10:00:14+00:00</updated>
<author>
<name>Michael Karcher</name>
<email>kernel@mkarcher.dialup.fu-berlin.de</email>
</author>
<published>2025-09-04T22:03:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c31cb4df701bb2f4af77921efdfbc6837f5879b1'/>
<id>urn:sha1:c31cb4df701bb2f4af77921efdfbc6837f5879b1</id>
<content type='text'>
[ Upstream commit 936fb512752af349fc30ccbe0afe14a2ae6d7159 ]

The referenced commit introduced exception handlers on user-space memory
references in copy_from_user and copy_to_user. These handlers return from
the respective function and calculate the remaining bytes left to copy
using the current register contents. This commit fixes a couple of bad
calculations. This will fix the return value of copy_from_user and
copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Fixes: 34060b8fffa7 ("arch/sparc: Add accurate exception reporting in M7memcpy")
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # on Oracle SPARC S7
Tested-by: Tony Rodriguez &lt;unixpro1970@gmail.com&gt; # S7, see https://lore.kernel.org/r/98564e2e68df2dda0e00c67a75c7f7dfedb33c7e.camel@physik.fu-berlin.de
Signed-off-by: Michael Karcher &lt;kernel@mkarcher.dialup.fu-berlin.de&gt;
Reviewed-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-5-1ca72dda195b@mkarcher.dialup.fu-berlin.de
Signed-off-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sparc: fix accurate exception reporting in copy_to_user for Niagara 4</title>
<updated>2025-10-15T10:00:14+00:00</updated>
<author>
<name>Michael Karcher</name>
<email>kernel@mkarcher.dialup.fu-berlin.de</email>
</author>
<published>2025-09-04T22:03:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d8857c43bf1648df8cff6d3b8ce388396a4a8e0'/>
<id>urn:sha1:5d8857c43bf1648df8cff6d3b8ce388396a4a8e0</id>
<content type='text'>
[ Upstream commit 5a746c1a2c7980de6c888b6373299f751ad7790b ]

The referenced commit introduced exception handlers on user-space memory
references in copy_from_user and copy_to_user. These handlers return from
the respective function and calculate the remaining bytes left to copy
using the current register contents. This commit fixes a bad calculation.
This will fix the return value of copy_to_user in a specific faulting case.
The behaviour of memcpy stays unchanged.

Fixes: 957077048009 ("sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.")
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # on Oracle SPARC T4-1
Signed-off-by: Michael Karcher &lt;kernel@mkarcher.dialup.fu-berlin.de&gt;
Reviewed-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-4-1ca72dda195b@mkarcher.dialup.fu-berlin.de
Signed-off-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara</title>
<updated>2025-10-15T10:00:14+00:00</updated>
<author>
<name>Michael Karcher</name>
<email>kernel@mkarcher.dialup.fu-berlin.de</email>
</author>
<published>2025-09-04T22:03:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a90ce516a73dbe087f9bf3dbf311301a58d125c6'/>
<id>urn:sha1:a90ce516a73dbe087f9bf3dbf311301a58d125c6</id>
<content type='text'>
[ Upstream commit 0b67c8fc10b13a9090340c5f8a37d308f4e1571c ]

The referenced commit introduced exception handlers on user-space memory
references in copy_from_user and copy_to_user. These handlers return from
the respective function and calculate the remaining bytes left to copy
using the current register contents. This commit fixes a couple of bad
calculations and a broken epilogue in the exception handlers. This will
prevent crashes and ensure correct return values of copy_from_user and
copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Fixes: 7ae3aaf53f16 ("sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.")
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # on SPARC T4 with modified kernel to use Niagara 1 code
Tested-by: Magnus Lindholm &lt;linmag7@gmail.com&gt; # on Sun Fire T2000
Signed-off-by: Michael Karcher &lt;kernel@mkarcher.dialup.fu-berlin.de&gt;
Tested-by: Ethan Hawke &lt;ehawk@ember.systems&gt; # on Sun Fire T2000
Tested-by: Ken Link &lt;iissmart@numberzero.org&gt; # on Sun Fire T1000
Reviewed-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-3-1ca72dda195b@mkarcher.dialup.fu-berlin.de
Signed-off-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III</title>
<updated>2025-10-15T10:00:14+00:00</updated>
<author>
<name>Michael Karcher</name>
<email>kernel@mkarcher.dialup.fu-berlin.de</email>
</author>
<published>2025-09-04T22:03:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ef9c94d7110e90260c06868cf1dcf899b9f25ee'/>
<id>urn:sha1:5ef9c94d7110e90260c06868cf1dcf899b9f25ee</id>
<content type='text'>
[ Upstream commit 47b49c06eb62504075f0f2e2227aee2e2c2a58b3 ]

Anthony Yznaga tracked down that a BUG_ON in ext4 code with large folios
enabled resulted from copy_from_user() returning impossibly large values
greater than the size to be copied. This lead to __copy_from_iter()
returning impossible values instead of the actual number of bytes it was
able to copy.

The BUG_ON has been reported in
https://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.de

The referenced commit introduced exception handlers on user-space memory
references in copy_from_user and copy_to_user. These handlers return from
the respective function and calculate the remaining bytes left to copy
using the current register contents. The exception handlers expect that
%o2 has already been masked during the bulk copy loop, but the masking was
performed after that loop. This will fix the return value of copy_from_user
and copy_to_user in the faulting case. The behaviour of memcpy stays
unchanged.

Fixes: ee841d0aff64 ("sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.")
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # on Sun Netra 240
Reviewed-by: Anthony Yznaga &lt;anthony.yznaga@oracle.com&gt;
Tested-by: René Rebe &lt;rene@exactcode.com&gt; # on UltraSparc III+ and UltraSparc IIIi
Signed-off-by: Michael Karcher &lt;kernel@mkarcher.dialup.fu-berlin.de&gt;
Reviewed-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-2-1ca72dda195b@mkarcher.dialup.fu-berlin.de
Signed-off-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC</title>
<updated>2025-10-15T10:00:14+00:00</updated>
<author>
<name>Michael Karcher</name>
<email>kernel@mkarcher.dialup.fu-berlin.de</email>
</author>
<published>2025-09-04T22:03:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7de3a75bbc8465d816336c74d50109e73501efab'/>
<id>urn:sha1:7de3a75bbc8465d816336c74d50109e73501efab</id>
<content type='text'>
[ Upstream commit 4fba1713001195e59cfc001ff1f2837dab877efb ]

The referenced commit introduced exception handlers on user-space memory
references in copy_from_user and copy_to_user. These handlers return from
the respective function and calculate the remaining bytes left to copy
using the current register contents. This commit fixes a couple of bad
calculations. This will fix the return value of copy_from_user and
copy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Fixes: cb736fdbb208 ("sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.")
Tested-by: John Paul Adrian Glaubitz &lt;glaubitz@physik.fu-berlin.de&gt; # on QEMU 10.0.3
Tested-by: René Rebe &lt;rene@exactcode.com&gt; # on Ultra 5 UltraSparc IIi
Tested-by: Jonathan 'theJPster' Pallant &lt;kernel@thejpster.org.uk&gt; # on Sun Netra T1
Signed-off-by: Michael Karcher &lt;kernel@mkarcher.dialup.fu-berlin.de&gt;
Reviewed-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Link: https://lore.kernel.org/r/20250905-memcpy_series-v4-1-1ca72dda195b@mkarcher.dialup.fu-berlin.de
Signed-off-by: Andreas Larsson &lt;andreas@gaisler.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free()</title>
<updated>2025-10-15T10:00:02+00:00</updated>
<author>
<name>Hengqi Chen</name>
<email>hengqi.chen@gmail.com</email>
</author>
<published>2025-09-16T23:26:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76e53c74f1168ed2bf3f7c2f2b24ad566a262c72'/>
<id>urn:sha1:76e53c74f1168ed2bf3f7c2f2b24ad566a262c72</id>
<content type='text'>
[ Upstream commit 6ff4a0fa3e1b2b9756254b477fb2f0fbe04ff378 ]

The current implementation seems incorrect and does NOT match the
comment above, use bpf_jit_binary_pack_finalize() instead.

Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management")
Acked-by: Puranjay Mohan &lt;puranjay@kernel.org&gt;
Signed-off-by: Hengqi Chen &lt;hengqi.chen@gmail.com&gt;
Acked-by: Song Liu &lt;song@kernel.org&gt;
Acked-by: Puranjay Mohan &lt;puranjay@kernel.org&gt;
Link: https://lore.kernel.org/r/20250916232653.101004-1-hengqi.chen@gmail.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>riscv, bpf: Sign extend struct ops return values properly</title>
<updated>2025-10-15T10:00:01+00:00</updated>
<author>
<name>Hengqi Chen</name>
<email>hengqi.chen@gmail.com</email>
</author>
<published>2025-09-08T01:24:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92751937f12a7d34ad492577a251c94a55e97e72'/>
<id>urn:sha1:92751937f12a7d34ad492577a251c94a55e97e72</id>
<content type='text'>
[ Upstream commit fd2e08128944a7679e753f920e9eda72057e427c ]

The ns_bpf_qdisc selftest triggers a kernel panic:

    Unable to handle kernel paging request at virtual address ffffffffa38dbf58
    Current test_progs pgtable: 4K pagesize, 57-bit VAs, pgdp=0x00000001109cc000
    [ffffffffa38dbf58] pgd=000000011fffd801, p4d=000000011fffd401, pud=000000011fffd001, pmd=0000000000000000
    Oops [#1]
    Modules linked in: bpf_testmod(OE) xt_conntrack nls_iso8859_1 [...] [last unloaded: bpf_testmod(OE)]
    CPU: 1 UID: 0 PID: 23584 Comm: test_progs Tainted: G        W  OE       6.17.0-rc1-g2465bb83e0b4 #1 NONE
    Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2024.01+dfsg-1ubuntu5.1 01/01/2024
    epc : __qdisc_run+0x82/0x6f0
     ra : __qdisc_run+0x6e/0x6f0
    epc : ffffffff80bd5c7a ra : ffffffff80bd5c66 sp : ff2000000eecb550
     gp : ffffffff82472098 tp : ff60000096895940 t0 : ffffffff8001f180
     t1 : ffffffff801e1664 t2 : 0000000000000000 s0 : ff2000000eecb5d0
     s1 : ff60000093a6a600 a0 : ffffffffa38dbee8 a1 : 0000000000000001
     a2 : ff2000000eecb510 a3 : 0000000000000001 a4 : 0000000000000000
     a5 : 0000000000000010 a6 : 0000000000000000 a7 : 0000000000735049
     s2 : ffffffffa38dbee8 s3 : 0000000000000040 s4 : ff6000008bcda000
     s5 : 0000000000000008 s6 : ff60000093a6a680 s7 : ff60000093a6a6f0
     s8 : ff60000093a6a6ac s9 : ff60000093140000 s10: 0000000000000000
     s11: ff2000000eecb9d0 t3 : 0000000000000000 t4 : 0000000000ff0000
     t5 : 0000000000000000 t6 : ff60000093a6a8b6
    status: 0000000200000120 badaddr: ffffffffa38dbf58 cause: 000000000000000d
    [&lt;ffffffff80bd5c7a&gt;] __qdisc_run+0x82/0x6f0
    [&lt;ffffffff80b6fe58&gt;] __dev_queue_xmit+0x4c0/0x1128
    [&lt;ffffffff80b80ae0&gt;] neigh_resolve_output+0xd0/0x170
    [&lt;ffffffff80d2daf6&gt;] ip6_finish_output2+0x226/0x6c8
    [&lt;ffffffff80d31254&gt;] ip6_finish_output+0x10c/0x2a0
    [&lt;ffffffff80d31446&gt;] ip6_output+0x5e/0x178
    [&lt;ffffffff80d2e232&gt;] ip6_xmit+0x29a/0x608
    [&lt;ffffffff80d6f4c6&gt;] inet6_csk_xmit+0xe6/0x140
    [&lt;ffffffff80c985e4&gt;] __tcp_transmit_skb+0x45c/0xaa8
    [&lt;ffffffff80c995fe&gt;] tcp_connect+0x9ce/0xd10
    [&lt;ffffffff80d66524&gt;] tcp_v6_connect+0x4ac/0x5e8
    [&lt;ffffffff80cc19b8&gt;] __inet_stream_connect+0xd8/0x318
    [&lt;ffffffff80cc1c36&gt;] inet_stream_connect+0x3e/0x68
    [&lt;ffffffff80b42b20&gt;] __sys_connect_file+0x50/0x88
    [&lt;ffffffff80b42bee&gt;] __sys_connect+0x96/0xc8
    [&lt;ffffffff80b42c40&gt;] __riscv_sys_connect+0x20/0x30
    [&lt;ffffffff80e5bcae&gt;] do_trap_ecall_u+0x256/0x378
    [&lt;ffffffff80e69af2&gt;] handle_exception+0x14a/0x156
    Code: 892a 0363 1205 489c 8bc1 c7e5 2d03 084a 2703 080a (2783) 0709
    ---[ end trace 0000000000000000 ]---

The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer
is treated as a 32bit value and sign extend to 64bit in epilogue. This
behavior is right for most bpf prog types but wrong for struct ops which
requires RISC-V ABI.

So let's sign extend struct ops return values according to the function
model and RISC-V ABI([0]).

  [0]: https://riscv.org/wp-content/uploads/2024/12/riscv-calling.pdf

Fixes: 25ad10658dc1 ("riscv, bpf: Adapt bpf trampoline to optimized riscv ftrace framework")
Signed-off-by: Hengqi Chen &lt;hengqi.chen@gmail.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Tested-by: Pu Lehui &lt;pulehui@huawei.com&gt;
Reviewed-by: Pu Lehui &lt;pulehui@huawei.com&gt;
Link: https://lore.kernel.org/bpf/20250908012448.1695-1-hengqi.chen@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
