| Age | Commit message (Collapse) | Author |
|---|
|
Add IPv4 and IPv6 test cases that program a route that uses a nexthop
object and check that two notifications are emitted for it, with the
second one carrying the RTM_F_TRAP flag.
The new route_nexthop_check() helper follows the same pattern as the
existing route_{addition,deletion,replacement}_check() helpers.
Without "ipv6: Hold RCU when emitting route hardware flags
notification", the IPv6 test case passes, but triggers suspicious RCU
usage splats. The IPv4 test case is added for completeness.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20261019140337.2886875-3-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
fib6_info_hw_flags_set() is called by drivers from process context
without RTNL or RCU. When the route uses a nexthop object,
rt6_nlmsg_size() and rt6_fill_node() access the nexthop's RCU protected
nexthop info and group pointers via rcu_dereference_rtnl(), resulting in
suspicious RCU usage splats [1].
Fix by holding RCU while sizing and filling the notification, like
fib_alias_hw_flags_set() already does. Switch to GFP_ATOMIC for the skb
allocation accordingly.
Reproducer:
# echo "10 0" > /sys/bus/netdevsim/new_device
# sysctl -wq net.ipv6.fib_notify_on_flag_change=1
# sysctl -wq net.ipv4.nexthop_compat_mode=1
# ip -6 nexthop add id 1 blackhole
# ip -6 route add 2001:db8:1::1/128 nhid 1
[1]
WARNING: suspicious RCU usage
7.3.0-rc7-virtme-g191aa41548b2 #38 Not tainted
net/ipv4/nexthop.c:1539 suspicious rcu_dereference_check() usage!
[...]
Workqueue: events nsim_fib_event_work
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
lockdep_rcu_suspicious.cold (kernel/locking/lockdep.c:6972)
nexthop_for_each_fib6_nh (net/ipv4/nexthop.c:1539 (discriminator 16))
rt6_nlmsg_size (net/ipv6/route.c:5728)
fib6_info_hw_flags_set (net/ipv6/route.c:6503)
nsim_fib6_rt_add (drivers/net/netdevsim/fib.c:671 drivers/net/netdevsim/fib.c:694)
nsim_fib6_rt_insert (drivers/net/netdevsim/fib.c:759)
nsim_fib_event_work (drivers/net/netdevsim/fib.c:856 drivers/net/netdevsim/fib.c:889 drivers/net/netdevsim/fib.c:1493)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
</TASK>
Fixes: 907eea486888 ("net: ipv6: Emit notification when fib hardware flags are changed")
Reported-by: Sashiko <netdev-bot+sashiko@kernel.org>
Closes: https://lore.kernel.org/netdev/179152182668.434549.18232968419539498055@kernel.org/
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20261019140337.2886875-2-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
MFGD register queries can exhaust EMAD retries and leave Mellanox
Spectrum switches stuck during boot or shutdown when running OpenWrt
built with GCC 15.
An example failure is shown below with the second line wrapped:
EMAD retries (5/5) (tid=9b544fc100001f35)
EMAD reg access failed (tid=9b544fc100001f35,reg_id=90f0(mfgd),
type=query,status=0(operation performed))
On an SN2100, the failure occurs during driver teardown on reboot.
On an SN3420, it occurs while probing mlxsw_spectrum during boot.
The register query API transmits the supplied payload to the device
before replacing it with the response. Both MFGD callers pass an
uninitialized stack buffer, so the request contains arbitrary register
field values and reserved bits. This makes the request depend on stack
contents and compiler code generation.
Initialize both MFGD query buffers in the firmware fatal event
configuration and reporter test paths. The initialization has been
confirmed to eliminate the boot and shutdown hangs on both switches.
The subsequent read-modify-write still preserves the other fields
returned by the device.
Also initialize the FORE fan fault query and the MOGCR mirroring policer
base query, which pass entirely uninitialized payloads. Restore the MTMP
query initialization in the temperature history reset path, where only
the slot and sensor index fields are set before querying the register.
This follows commit 5b0907407e7f ("mlxsw: core: Zero payload buffers for
couple of registers"), which initialized other query payloads after a
firmware field length bug caused firmware to consume uninitialized data.
Tested with firmware 2020.1148 and with 2016.3900 from linux-firmware.
Fixes: 7d83ee111008 ("mlxsw: core: Introduce fw_fatal health reporter")
Fixes: 2c6a33cd334b ("mlxsw: core: Extend hwmon interface with fan fault attribute")
Fixes: 4039504e6a0c ("mlxsw: spectrum_span: Allow setting policer on a SPAN agent")
Fixes: b890ad418e1f ("mlxsw: core_hwmon: Extend internal structures to support multi hwmon objects")
Cc: stable@vger.kernel.org
Signed-off-by: Til Kaiser <mail@tk154.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261014173117.26305-1-mail@tk154.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Switch from <module>-objs to <module>-y to eliminate ifdefs and simplify
conditional object list construction. Drop the obsolete trailing
comment.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Alvin Šipraga <alvin.sipraga@analog.com>
Link: https://patch.msgid.link/20261019-realtek_mkf-v1-1-3246a77d5782@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
net.unix.max_dgram_qlen is parsed as a signed int and copied to the u32
sock::sk_max_ack_backlog when an AF_UNIX socket is created. Consequently,
a negative value such as -1 is accepted and converted to UINT_MAX. Since
the receive queue length is also u32, its fullness check cannot become true
for that limit.
max_dgram_qlen has no documented negative sentinel. Its existing signed
interface represents nonnegative values only through INT_MAX; negative bit
patterns are not a supported encoding for the upper half of the u32
consumer range.
Switch to proc_dointvec_minmax and make the established 0..INT_MAX input
range explicit. This rejects negative values without adding new accepted
values or changing the default and zero-value behavior. Very large valid
values can still make the queue limit impractical to reach; this change
corrects the input domain rather than imposing a new resource ceiling.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Yingjie Wang <1075151112@qq.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/tencent_A643419B56079E9A448D97922763FF069F08@qq.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 FPU state updates from Borislav Petkov:
- Document and cleanup the signal frame handling with the goal to allow
process migration between CPUs with different FPU capabilities but
which use only a common set of FPU features, i.e., think
checkpoint/restore (Andrei Vagin)
- Consolidate how XSTATE features are checked by doing them once during
boot with the intent of removing cpu_has_xfeatures(). Latter will
happen in the next cycle (Eric Biggers)
- Other cleanups
* tag 'x86_fpu_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/fpu: Remove additional remnants of math emulation
x86/fpu: Remove unnecessary checks for X86_FEATURE_FPU
selftests/x86: Add tests for signal frame FPU portability
x86/fpu: Pre-fault only required size of xstate buffer
x86/fpu: Fix potential underflow in xstate_calculate_size()
x86/fpu: Document reasoning of FX-only fallback
x86/fpu: Extract restore_from_ia32_fxstate() and clean up fpu__restore_sig()
x86/fpu: Clean up and rename variables in signal frame handling
x86/fpu: Document signal frame layout and portability
xor: Add AVX-512 optimized xor_gen()
xor: Remove redundant X86_FEATURE_OSXSAVE check
lib/crc: x86: Stop using cpu_has_xfeatures()
lib/crypto: x86: Stop using cpu_has_xfeatures()
crypto: x86 - Stop using cpu_has_xfeatures()
um: Check for missing AVX and AVX-512 xstate bits
x86/fpu: Check for missing AVX and AVX-512 xstate bits
|
|
reg_vif_xmit() hands the skb to ip6mr_cache_report() as an
MRT6MSG_WHOLEPKT report. skb_realloc_headroom() copies skb->cb[]
into the report, which is queued to the mroute socket, where
rawv6_recvmsg() reads it as IP6CB.
By the time the pim6reg device transmits the packet, skb->cb[] is
not IP6CB anymore: qdisc_pkt_len_init() overwrites iif and ra,
and any qdisc installed on the device (fq, fq_codel, pie, cake...)
or a tc BPF program writing skb->cb[] fills the area holding
dst0, srcrt, dst1, lastopt and flags.
Since commit dd433671fef3 ("ipv6: validate extension header length
before copying to cmsg") these stale offsets can no longer cause
out-of-bounds reads, but the mroute socket can still receive bogus
IPV6_PKTINFO ifindex and extension header ancillary data.
Clear IP6CB before building the report. The skb is freed right
after, so nothing else depends on its control block.
Fixes: 14fb64e1f449 ("[IPV6] MROUTE: Support PIM-SM (SSM).")
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The changed four tests can print [FAIL] subtests while still exiting with
status 0. Their log_test(), aka log_test_expected() in lib.sh, helpers
record a failure in ret, but the scripts never propagate ret to the exit
code, so a kselftest runner treats the run as a pass.
Initialize ret and exit with it at the end of each script so failed
subtests are reflected in the exit status.
Signed-off-by: Hangbin Liu <liuhangbin@kylinos.cn>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The Acer Nitro AN16-41 supports the Predator Sense v4 platform profile,
hwmon sensors and fan control, but currently needs the predator_v4
module parameter to expose them. Add a DMI quirk for it, reusing the
Nitro AN515-58 quirk entry since the feature set is the same.
Tested on BIOS V1.03: all five platform profiles are offered by the
firmware and switching them changes the fan curve, both fan speeds and
the temperature sensors read correctly, and pwm1/pwm2 work in custom,
maximum and automatic mode.
Assisted-by: LLM
Signed-off-by: Dennis Nilsson <kontakt@dennisnilsson.se>
Link: https://patch.msgid.link/20261017-acer-nitro-an16-41-v1-2-c2e7a0ee7303@dennisnilsson.se
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
On some Nitro models using the Predator Sense v4 interface, such as the
Nitro AN16-41, the mode key raises WMID_GAMING_TURBO_KEY_EVENT with
key_num 0x4 instead of 0x5. The driver routes key_num 0x4 to
acer_toggle_turbo(), which returns immediately on machines without
ACER_CAP_TURBO_LED because WMID_gaming_get_u64() rejects the missing
capability, so the key press is silently dropped.
Only toggle turbo for key_num 0x4 when the turbo LED capability is
present, and cycle the platform profile otherwise. Machines with the
turbo quirk keep their current behaviour, and on every other machine
key_num 0x4 was previously a no-op.
Tested on an Acer Nitro AN16-41 (BIOS V1.03), where the mode key sends
the event payload 07 04 01 00 and now cycles the platform profile.
Assisted-by: LLM
Signed-off-by: Dennis Nilsson <kontakt@dennisnilsson.se>
Link: https://patch.msgid.link/20261017-acer-nitro-an16-41-v1-1-c2e7a0ee7303@dennisnilsson.se
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
__rds_conn_create() calls trans->conn_free() with rds_conn_lock held
and IRQs disabled when it loses the race to insert a connection.
rds_ib_conn_free() takes the device list lock with spin_lock_irq() and
releases it with spin_unlock_irq(), so IRQs are turned on while
rds_conn_lock is still held:
raw_local_irq_restore() called with IRQs enabled
WARNING: kernel/locking/irqflag-debug.c:10 at warn_bogus_irq_restore+0xc/0x20
_raw_spin_unlock_irqrestore+0x67/0x80
__rds_conn_create+0x1de5/0x2290
rds_conn_create_outgoing+0x43/0x60
rds_sendmsg+0xfca/0x20e0
__sys_sendto+0x408/0x5a0
It needs an RDS socket bound to an address on an RDMA device (e.g. rxe)
and two concurrent sendto() calls to the same new destination.
The TCP and loopback ->conn_free() callbacks already use irqsave, so
do the same here.
Fixes: 745cbccac3fe ("RDS: Rewrite connection cleanup, fixing oops on rmmod")
Reported-by: syzbot+c3741bb338b5c6d6a4aa@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c3741bb338b5c6d6a4aa
Cc: stable@vger.kernel.org
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Mahe Tardy says:
====================
bpf: Add bpf_ksock_sendto() kfunc
This patch series improves the bpf_ksock infrastructure in line with the
work proposed during Prague Plumbers 2026 presentation[^1] by adding
the bpf_ksock_sendto() kfunc to complement the bpf_ksock_send().
This is useful when using ksock to reply to differents peers while
reusing the same UDP socket and generally works toward the goal of ksock
to support the basic socket operations.
[^1]: https://lpc.events/event/20/contributions/2430/
v2 updates:
- remove the LSM verifier filter refinements (alexei)
- remove allowing calling connect() from the send path (alexei)
- change order of the tests patches for signature definition (sashiko)
v1: https://lore.kernel.org/bpf/DM9RCU3BDWEG.1C32ZIVU95S76@gmail.com/
====================
Link: https://patch.msgid.link/20261020155848.75711-1-mahe.tardy@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Similarly to '7b0dfbf5776b ("selftests/bpf: Test forbidden
bpf_ksock_send() LSM attach")', tests that the verifier filter prevents
bpf_ksock_sendto() to be called in a LSM program attached to
security_socket_sendmsg() as it would create a direct recursion.
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020155848.75711-4-mahe.tardy@gmail.com
|
|
These tests are covering that:
1. sendto() on a unconnected UDP socket works (and that the socket stays
unconnected, i.e. send() on it fails with -EDESTADDRREQ).
2. sendto() on a connected UDP socket with a NULL address is equivalent
to send().
3. sendto() on a connected socket with an explicit address doesn't
change the peer of the socket (send() after sendto() still sends to
the original connected address).
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020155848.75711-3-mahe.tardy@gmail.com
|
|
The motivation is to plumb more of the socket API into ksock, thus
supporting sendto() in addition to send() which makes a lot of sense in
the context of UDP sockets which are the only type currently supported.
This is useful when ksock is used to reply to specific addresses or send
to multiple addresses.
Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020155848.75711-2-mahe.tardy@gmail.com
|
|
Alexei Starovoitov says:
====================
bpf: Unwinding with unwind_goto and unwind_exit
From: Alexei Starovoitov <ast@kernel.org>
1. What is the problem?
A rust panic or a C++ exception has to run Drop impls or destructors of
every frame it passes through. bpf_throw() discards the frames, so the
verifier doesn't let a frame that owns a lock or a reference throw. In rust
every index and every unwrap() can panic.
2. Is it worth solving?
Without it rust-bpf [1] drops all landing pads and a panic is bpf_throw().
A prog that can panic with a guard held doesn't load.
3. Is there a simpler way?
[2] keeps the normal path free of unwind code. llvm emits a table, libbpf
passes it to the kernel, bpf_unwind() walks the stack and rewrites return
addresses, and the verifier models hidden edges from calls to pads. That's
1400 lines in the kernel, with new uapi and two kfuncs, and 440 lines in
libbpf.
Here the edge from a call to its pad is an insn, and so is the other way
to leave a frame [3]:
ret exit
invoke foo unwind pad call foo; unwind_goto pad
resume r0 = 0; unwind_exit
Pads are ordinary code. The verifier learns one bit: how the callee left.
The normal path is free of unwind code too: JITs emit nothing for
unwind_goto, and exit is what it was.
200 lines in patch 1 and 100 lines in each JIT.
4. Will the api and the layers last?
Two new insns: one more kind of BPF_JCOND and one more kind of BPF_EXIT.
No kfuncs, no BTF, no changes in libbpf and other loaders.
The source level entry point is _Unwind_RaiseException() of the Itanium
ABI. It's what the runtimes of rust and C++ call on other architectures.
unwind_exit returns r0 like exit does. Today it's 0. That's where an
exception object would go.
5. Is it good taste?
Every frame returns through its own epilogue. The only question is where it
returns to. That's one bit, and it's a bit of control flow. v1 kept it in
a register.
It's not specific to rust. A C++ prog with throw, catch and destructors
compiles, loads and runs. It's a selftest in patch 5.
The llvm side is a new PR [3]. It replaces [4].
v3 -> v4:
- CI stayed red on x86-64. Call depth accounting was not the reason. CI
builds x86-64 with KASAN, where the JIT wraps a load in pushes, a call
and pops. The patterns of two __jited tests took that call for the call
of the subprog. Now they start after the loads.
- When the callee never exits, what follows unwind_goto is seen only
speculatively. It was removed as dead code, and other code moved to where
the cpu predicts the return. Now 'goto pc-1' is there (sashiko).
- unwind_exit of an async or an exception callback is exit, like in the
main prog. It was rejected. A sync callback still cannot unwind.
- arm64: no autia1716 and pacia1716. The address of the pad isn't signed.
The epilogue authenticates LR as it is, and the offset of the pad is
added to it afterwards.
- BPF_UNWIND_EXIT is enum instead of #define.
- unwind_attach and unwind_cxx skip when JIT is disabled, and don't define
ENOTSUPP (bpf-ci).
v2 -> v3:
- bpf_unwind_target() is back in the JITs. In core.c it broke the build on
MIPS, where struct exception_table_entry has no fixup (sashiko, bpf-ci).
- CI was red on x86-64: two __jited tests didn't expect call depth
accounting in front of a call (bpf-ci).
- A global subprog that returns 16 bytes couldn't unwind: the verifier
checks r0 and r2 at unwind_exit, and llvm set r0 only. Fixed in llvm.
Patch 6 is Kumar's test.
- freplace: unwind_exit of an extension was exit, so the exception was lost
(Eduard). Now the extension returns to the pad of the caller of what it
replaced. An extension that can unwind replaces only a subprog that can.
fexit cannot attach to such an extension.
- unwind_exit makes the cpu mispredict the return. Without CAP_PERFMON
the verifier looks at what follows unwind_goto as a speculative path
(bpf-ci).
- unwind_goto was 'call pc+0' in the xlated dump: BPF_JCOND is the same
opcode as BPF_CALL_ARGS.
- selftests: 'the callee never returns' looks at xlated insns, and 'the way
the callee left is a part of the state' has BPF_F_TEST_STATE_FREQ.
Neither tested what it said (bpf-ci). New tests for async and exception
callbacks, speculation and freplace. Every check that the series adds
was removed in turn to see that a test fails.
- llvm: a pad doesn't set r0 when it only writes w0. Yonghong's callx case
from [4] is a lit test.
- Rebased.
v1 -> v2:
- unwind_goto and unwind_exit instead of 'if r3 != 0 goto pad' and
'r3 = 1; exit' (Kumar).
- JIT support is not an optimization anymore. There are no shape tests, no
look at jump_target, which was stale (sashiko), no exit that looks at r3
and no fallback to a branch.
- r3 is an argument again and nothing else. In v1 a subprog that didn't
write it passed it through, and fentry didn't restore it (bpf-ci).
- Async and exception callbacks cannot unwind (sashiko).
- No BTF decl_tag, which was matched by prefix (bpf-ci). It works without
BTF.
- x86 private stack is supported.
- Tail call and ld_abs are allowed.
- selftests: no #ifdef by arch, which broke the build on the rest of them.
The messages are checked. fentry is attached and the target is run.
Skips say why (bpf-ci).
- clang defines __BPF_FEATURE_UNWIND.
v3: https://lore.kernel.org/bpf/20261020043319.3031996-1-alexei.starovoitov@gmail.com/
v2: https://lore.kernel.org/bpf/20261019051846.3012089-1-alexei.starovoitov@gmail.com/
v1: https://lore.kernel.org/bpf/20261018010246.1643877-1-alexei.starovoitov@gmail.com/
Tested on x86-64 in kvm with KASAN, like CI does: test_progs,
test_progs-no_alu32, test_progs-cpuv4 and test_verifier, all of them in
full. The new tests also with retbleed=stuff. C, C++ and rust progs built
with [3] were run on x86-64 and arm64, with and without bpf_jit_harden=2.
arm64 is qemu, with and without pointer authentication, and a small loader
instead of test_progs. v3 passed test_progs on arm64 in CI.
[1] https://github.com/4ast/rust-bpf
[2] https://lore.kernel.org/bpf/20261017025129.1914859-1-yonghong.song@linux.dev/
[3] https://github.com/llvm/llvm-project/pull/233649
[4] https://github.com/llvm/llvm-project/pull/233140
====================
Link: https://patch.msgid.link/20261020181320.1284798-1-alexei.starovoitov@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
Global subprograms returning a 16-byte scalar use R0:R2. The
verifier therefore checks both registers at every ordinary and unwind
exit.
LLVM lowers a resume to "r0 = 0; unwind_exit". If cleanup code does not
happen to initialize R2, the verifier rejects the unwind path with:
R2 !read_ok
Extend unwind_cxx with a global unsigned __int128-returning subprogram
whose cleanup only releases its RCU read lock. Load it separately so
the existing cases continue to run and the failure is attributed to
this case. Check both the normal aggregate return and caught exception.
The test passes once LLVM defines R2 before emitting unwind_exit.
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-7-alexei.starovoitov@gmail.com
|
|
static __noinline int inner(int len)
{
rcu_guard guard;
if (len > 100)
throw 1;
return len;
}
static __noinline int middle(int len)
{
preempt_guard guard;
return inner(len) + 1;
}
SEC("tc") int catches(struct __sk_buff *skb)
{
try {
return middle(skb->len);
} catch (...) {
return 42;
}
}
The exception passes through two frames. The destructors call
bpf_rcu_read_unlock() and bpf_preempt_enable(). The verifier insists on
both, and the test checks that they ran in that order.
In the second prog nobody catches. The destructors run and the prog
returns 0.
All that is left of the C++ runtime is four one line functions.
__cxa_throw() calls _Unwind_RaiseException(), which llvm lowers.
progs/*.cpp are built like progs/*.rs: by clang only and without skeletons.
vmlinux.h and bpf_helpers.h are not C++, so the prog declares what it
needs.
clang that lowers unwinding [1] defines __BPF_FEATURE_UNWIND. Without it
the object has no progs and the test is skipped.
[1] https://github.com/llvm/llvm-project/pull/233649
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-6-alexei.starovoitov@gmail.com
|
|
The tests spell the two insns out as raw insns, so they don't depend on
llvm version.
verifier_unwind:
- A static subprog, a global one and a callee of callx leave either way at
run time, through one and two frames. The verifier follows a static
subprog, so the tests derive the argument from skb->len or read it from
a map.
- r0 of unwind_exit, r6-r9 and the stack are there in the pad. r1-r5
are not readable.
- A pad is checked like any other code: it has to drop rcu_read_lock.
- How the callee left is a part of the verifier state: two states that
differ only in that are not pruned.
- The pad of a call of a global subprog is always checked.
- A callee that never returns, where unwind_goto stays and 'goto pc-1'
follows it, and one that never unwinds, where it goes away with the pad.
- What follows unwind_goto runs speculatively: with CAP_BPF only there is
nospec in front of an insn that isn't safe with r0 of unwind_exit.
- unwind_exit without unwind_goto after the call.
- unwind_goto that doesn't follow a call of a subprog or is a jump target.
- Reserved fields.
- A sync callback cannot unwind. What it calls can.
- unwind_exit of an async and of an exception callback is exit.
- Tail call and ld_abs in a subprog that can unwind.
- unwind_exit of the main prog is exit.
- What x86-64 and arm64 JITs emit. With KASAN x86-64 JIT wraps a load in
pushes, a call and pops, so the patterns start after the loads.
- Private stack. On x86-64 r9 has to be restored on the way to the pad.
The last one has to look at the return value of a prog that uses private
stack. raw_tp is such a prog. Its test_run doesn't take a packet, so let
test_loader run it like it runs syscall progs.
unwind_attach, with the caller run after every attach:
- fentry on a subprog that unwinds. fexit is refused.
- freplace of a subprog that unwinds by an extension that returns and by
one that unwinds. The caller goes on after the call or in the pad.
- An extension that unwinds cannot replace a subprog that doesn't.
Every check that the series adds was removed in turn to see that a test
fails.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-5-alexei.starovoitov@gmail.com
|
|
bpf arm64
call inner bl inner
mov x8, x0
unwind_goto pad
w0 = w6 mov w8, w19
Like on x86 unwind_goto is an extable entry and no code.
unwind_exit returns to the pad past 'mov x8, x0'. That's fine: r0 is x8,
and the epilogue of the callee copies it to x0 and leaves x8 as it is.
With pointer authentication LR in the frame record is signed. unwind_exit
doesn't sign the address of the pad. It looks up the offset of the pad from
its return address. Then it's the epilogue as it is, and the offset is
added to LR after autiasp:
stp x8, x1, [sp, #-16]!
ldr x0, [x29, #8]
bl bpf_unwind_fixup
mov x10, x0
ldp x8, x1, [sp], #16
...
ldp x29, x30, [sp], #16
mov x0, x8
autiasp
add x30, x30, x10
ret
So LR is authenticated like in exit, and the frame record stays as it is.
bpf_unwind_fixup() strips the signature for the lookup.
RET is not subject to BTI.
r0 and r2 are what a subprog returns, so x8 and x1 are saved around the
lookup.
Like on x86 the offset is 0 when the kernel called the subprog as
a callback, and unwind_exit of the main prog is exit, unless it's
an extension.
The private stack pointer is in a callee saved register. Unlike x86 there
is nothing to undo after the call.
Tested in qemu with -cpu max and -cpu cortex-a72, i.e. with and without
pointer authentication.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-4-alexei.starovoitov@gmail.com
|
|
bpf x86
call inner call inner
unwind_goto pad
w0 = w6 mov eax, ebx
r0 = 0 xor eax, eax
unwind_exit push rax
push rsi
mov rdi, [rbp + 8]
call bpf_unwind_target
mov [rbp + 8], rax
pop rsi
pop rax
leave
ret
unwind_goto is an extable entry and no code. unwind_exit looks its return
address up there and returns to the pad. r0 and r2 are what a subprog
returns, so rax and rsi are saved around the lookup.
When there is no entry, the kernel called the subprog as an async or an
exception callback, and unwind_exit is exit.
The caller of the main prog doesn't tell exit from unwind_exit, so there
it's exit. An extension is different. freplace is a jump, so its return
address is the one of the subprog that it replaced.
With private stack r9 is saved around a call, and 'pop r9' has to be done
on the way to the pad too. In such progs unwind_goto is:
push r9
call foo
pop r9 <- exit returns here
jmp 1f
pop r9 <- unwind_exit returns here
jmp pad
1:
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-3-alexei.starovoitov@gmail.com
|
|
Rust Drop, C++ destructors and __attribute__((cleanup)) in C have to run
when a panic or an exception passes through a frame.
v1 [1] did it with a flag in r3 and 'if r3 != 0 goto pad' after the call.
Three bugs that the bots found there had the same cause: r3 is an ordinary
register, and JITs guessed the meaning from the shape of the code.
Kumar suggested new insns instead [2]:
unwind_goto pad BPF_JMP | BPF_JCOND, src_reg = BPF_UNWIND_GOTO
unwind_exit BPF_JMP | BPF_EXIT, src_reg = BPF_UNWIND_EXIT
'call foo; unwind_goto pad' goes to the pad when foo left with unwind_exit
and falls through when it left with exit. No register says which one it
was. In everything else unwind_exit is exit.
llvm lowers unwinding to them [3]:
ret exit
invoke foo unwind pad call foo; unwind_goto pad
resume r0 = 0; unwind_exit
call _Unwind_RaiseException r0 = 0; unwind_exit
invoke _Unwind_RaiseException goto pad
In a function that returns 16 bytes it's 'r0 = 0; r2 = 0; unwind_exit'.
Landing pads are ordinary blocks, so the verifier checks them like any
other code. A pad that forgets to drop a lock or a reference is a leak on
that path. There are no tables, no stack walk, no kfuncs, no BTF and
nothing to do for libbpf and other loaders.
In the verifier:
- unwind_goto has to follow a call or callx of a subprog and cannot be
a jump target. For cfg, liveness and the rest it's one more conditional
jump, like may_goto.
- How the callee left is one bit of the verifier state. It lives from
the exit of the callee to the next insn. states_equal() looks at it,
since the registers can be the same either way.
- unwind_exit is rejected when unwind_goto doesn't follow the call.
- A global subprog that has unwind_exit can leave either way. Both are
explored after the call, like it's done for might_throw.
- A sync callback cannot unwind. The helper that calls it doesn't expect
that: bpf_loop() would go on.
- unwind_exit of the main prog is exit, unless it's an extension. So it is
in async and exception callbacks. The kernel calls them, and there is no
frame to unwind to.
- An extension leaves either way, like the subprog that it replaced.
freplace is a jump, so the extension returns to the caller of
the subprog. An extension that has unwind_exit can replace only a subprog
that has it too. Otherwise there is no unwind_goto after the calls.
- Of tracing progs only fentry can attach to a subprog or an extension
that has unwind_exit. It would return to the trampoline that called it.
- unwind_exit changes its return address, so the cpu mispredicts
the return and runs what follows unwind_goto speculatively. Without
CAP_PERFMON the verifier looks at that path too.
- unwind_goto goes away together with a pad that turned out to be dead
code. It stays when what follows it is dead code. The cpu predicts that
the callee returns there, so 'goto pc-1' takes the place of the dead
code. Otherwise its removal would move other code there.
JITs don't emit a branch:
unwind_goto:
extable[n++] = { ret_addr - 1 -> pad }
unwind_exit:
my_ret_addr = bpf_unwind_target(my_ret_addr)
epilogue
So exit and the normal path after the call cost nothing. Every frame fixes
only its own return address. There is no stack walk. The lookup is what
the page fault handler does for bpf progs.
The interpreter cannot do that, so the prog has to be JITed, and JITs opt
in with bpf_jit_supports_unwind(). x86-64 and arm64 are in the next
patches.
BPF_JCOND is the same opcode as BPF_CALL_ARGS of the interpreter, and
BPF_UNWIND_GOTO is the same number as BPF_PSEUDO_CALL. may_goto is gone by
the time a prog is dumped, unwind_goto is not. bpf_insn_prepare_dump()
tells them apart: a prog with unwind_goto is always JITed.
Compared to v1 there is no BTF decl_tag and no 'r3 = 0' before every exit.
Tail call and ld_abs are fine in a subprog that can unwind, since they
leave it like exit does.
unwind_exit doesn't set r0. An implicit definition of r0 would need
special cases in backtracking, in liveness and in the check of the return
value of the main prog. A plain 'r0 = 0' in front of it needs none.
Rust
rust-bpf [4] builds with that llvm as it is. The programs are built with
-C panic=unwind. The panic handler prints the message and calls
_Unwind_RaiseException().
exc_cleanup.rs panics three frames deep, with preemption disabled in one
frame and rcu_read_lock held in another. All Drop impls run and the prog
returns 0.
scx_simple.rs is 2195 insns with 48 unwind_goto, 20 of them after callx,
and 16 unwind_exit. With r3 it was 2216 insns. scx_cosmos.rs is 3694 insns
with 68 and 18. It was 3716.
C++
Exceptions work too. This compiles, loads and runs:
struct rcu_guard {
rcu_guard() { bpf_rcu_read_lock(); }
~rcu_guard() { bpf_rcu_read_unlock(); }
};
static __noinline int inner(int len)
{
rcu_guard guard;
if (len > 100)
throw 1;
return len;
}
SEC("tc") int prog(struct __sk_buff *skb)
{
try {
return inner(skb->len);
} catch (...) {
return 42;
}
}
It returns 64 for a packet of 64 bytes and 42 for a packet of 200 bytes.
The destructor runs in both cases, otherwise the verifier would reject
the prog. 'throw' is a jump to the pad with the destructor. 'catch' is
unwind_goto:
inner:
w6 = w1
call bpf_rcu_read_lock
if w6 s< 101 goto ret
r1 = exc_obj ll
*(u32 *)(r1 + 0) = 1
goto pad
ret:
call bpf_rcu_read_unlock
w0 = w6
exit
pad:
call bpf_rcu_read_unlock
r0 = 0
unwind_exit
prog:
w6 = *(u32 *)(r1 + 0)
w1 = w6
call inner
unwind_goto catch
out:
w0 = w6
exit
catch:
w6 = 42
goto out
It needs -fexceptions -funwind-tables and four one line __cxa_*()
functions, where __cxa_throw() calls _Unwind_RaiseException().
Every pad is entered whatever was thrown, so llvm takes catch (...) only.
It's a selftest in patch 5.
[1] https://lore.kernel.org/bpf/20261018010246.1643877-1-alexei.starovoitov@gmail.com/
[2] https://lore.kernel.org/bpf/DM7KR7J8VY2T.1CZIRUF6QRCWG@gmail.com/
[3] https://github.com/llvm/llvm-project/pull/233649
[4] https://github.com/4ast/rust-bpf
Suggested-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020181320.1284798-2-alexei.starovoitov@gmail.com
|
|
Currently, hp_wmi_hwmon_is_visible() checks whether fan RPM queries
succeed before exposing fan1_input and fan2_input, but pwm1_enable
remains visible always, even when fan support is unavailable. On some
devices, such as certain Omnibook models, the firmware does not provide
functional WMI fan methods. Exposing pwm1_enable on these devices can
mislead userspace and cause fan mode changes to fail.
Additionally, some firmware implementations provide stub methods
that return an all-zero buffer instead of an error. In this case,
hp_wmi_get_active_fan_speed() and hp_wmi_get_fan_speed() can report 0
RPM even when the fan is physically spinning.
Use the result of fan count query (fetched from firmware once in
hp_wmi_setup_fan_settings(), and cached in hwmon private data) to
determine whether fan related attributes should be exposed.
The fan count query can have the following outcomes:
* Negative: The WMI query failed. Other fan-related queries are also
expected to fail, so disable fan support.
* Zero (stub firmware): The methods return zero-filled responses without
providing functional fan support, so disable fan support.
* Zero (genuine firmware): No fans are exposed through WMI, so disable
fan support.
* Positive (1 or 2): Firmware reports one or more fans, so allow fan
support. Per-channel RPM queries continue to determine which
individual fan input attributes are exposed.
When fan support is unavailable, hide the fan and PWM attributes and
skip applying the initial fan settings.
Tested on: HP OmniBook 5 Laptop 16-ag1xxx (board: 8DF4)
Tested-by: Lorenzo Collevecchio <lorenzocollevecchio17@gmail.com>
Reported-by: Lorenzo Collevecchio <lorenzocollevecchio17@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=222138
Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
Link: https://patch.msgid.link/20261017132421.279522-1-krishna.chomal108@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
mlx5 couples HW-GRO with tcp-data-split. If a user sets rx-gro-hw on ->
tcp-data-split on -> rx-gro-hw off, the driver will leave HW-GRO on.
mlx5e_ethtool_set_tcp_data_split() calls netdev_update_features() when
tcp-data-split goes from enabled to disabled in case HW-GRO needs to be
released. mlx5e_fix_features() reads the new HDS config from
dev->cfg_pending, so HW-GRO is released before all ring parameters are
validated.
If the subsequent call to mlx5e_ethtool_set_ringparam() fails, the
ethtool core discards the pending change and reports tcp-data-split
enabled. The device is no longer splitting, and subsequent ring changes
are blocked.
Move the call to netdev_update_features() after
mlx5e_ethtool_set_ringparam() exits successfully.
The issue was discovered by manual code inspection during review of
a change that stops mlx5 users from disabling tcp-data-split. It was
reproduced on a ConnectX-7 with ethtool alone.
Steps to reproduce:
ethtool -K eth0 rx-gro-hw on
ethtool -G eth0 tcp-data-split on
ethtool -K eth0 rx-gro-hw off # HW-GRO kept on for tcp-data-split
ethtool -G eth0 tcp-data-split off rx 1 # de-sync driver & kernel state
netlink error: mlx5_core: rx (1) < min (16)
netlink error: Invalid argument
ethtool -G eth0 rx 1024 # valid ring changes are now blocked
netlink error: mlx5_core: TCP-data-split is not supported when GRO HW is disabled
netlink error: Invalid argument
This is not a terminal state, users can recover by setting rx-gro-hw on.
With the fix, the failing ringparam set leaves rx-gro-hw on and later
ring changes succeed.
Fixes: 46bcce5dfd33 ("net/mlx5e: Support ethtool tcp-data-split settings")
Reported-by: Björn Töpel <bjorn@kernel.org>
Closes: https://lore.kernel.org/87se2grw3d.fsf@all.your.base.are.belong.to.us/
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Acked-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20261017005401.1582755-1-dimitri.daskalakis1@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next
Pablo Neira Ayuso says:
====================
Netfilter updates for net-next
The following patchset contains Netfilter/IPVS updates for net-next:
1) Disable br_netfilter in userns and schedule it for removal in 2027,
from Florian Westphal.
2) Update selftest nft_queue.sh to make it more stable on debug
kernels, from Jakub Kicinski.
3) Fix a overflow in IPVS sync messages which can only happen in very
old 2.6 kernels, from Julian Anastasov.
4) Finer grain packet drop in nfnetlink_queue when dependency objects
are going away, from Antonio Ojea.
5) Add a selftest for the nfnetlink_queue packet drop case, also
from Antonio Ojea.
6) Flush conntrack gc worker when existing netns to address a unlikely
UaF, from Florian Westphal.
7) Switch nf_tables chain types to use rcu, otherwise module removal
can trigger UaF, also from Florian.
8) Remove redundant parsing in nft_exthdr for the tcp options case,
from Fernando F. Mancera.
9) Remove redundant skb_header_pointer() calls in nft_exthdr for tcp
options, from Fernando F. Mancera.
10) Fix conntrack_vrf.sh selftest return value in zone subtest,
from Florian Westphal.
11) Restrict raw table in nft_compat to specific family, hook and
priority, from Florian Westphal.
Prepare the flowtable to support for IPv4 over IPv6 tunneling and
vice-versa, this includes 4 patches from Lorenzo Bianconi.
12) Explicitly set inner protocol when popping header, this is not
needed for the existing IPIP and IP6IP6 case because skb->protocol
remains the same.
13) Simplify tuple tunnel information fill up when parsing outer
tunnel IP headers.
14) Add a new encap_proto which determines the outer tunnel protocol
family.
15) Prepare flowtable forwarding path to deal with mixed IPv4-IPv6
tunnels.
* tag 'nf-next-26-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
netfilter: flowtable: unify tunnel push for IPv4 and IPv6
netfilter: flowtable: add encap_proto to flow_offload_tunnel
netfilter: flowtable: populate tunnel tuple regardless of inner protocol
netfilter: flowtable: set inner protocol when popping tunnel header
netfilter: nft_compat: restrict raw table targets/matches
selftests: netfilter: fix return value in zone subtest
netfilter: nft_exthdr: avoid 60 bytes stack buffer in TCP option mangling
netfilter: nft_exthdr: remove redundant op parsing in tcp_set_init
netfilter: nf_tables: switch chain_types array to rcu
netfilter: conntrack: fix unlikely UaF in gc worker
selftests: netfilter: nft_queue: check the scope of the hook drop flush
netfilter: nf_queue: limit the hook drop flush to the unregistered hook point
ipvs: fix buffer overflow when sending sync messages
selftests: netfilter: nft_queue.sh: only queue icmp echo request/reply
netfilter: disable br_netfilter in user namespaces
====================
Link: https://patch.msgid.link/20261018005638.1776148-1-pablo@netfilter.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
MANA doesn't support byte queue limits, so each TX queue can hold 256
WQEs by default, and up to 16384, of up to 64 KB TSO packets, before the
qdisc layer sees any backpressure. This adds latency to all the flows
sharing a queue, and defeats AQM qdiscs such as fq_codel, which rely on
BQL to keep the driver queues short.
Report the bytes queued and completed to BQL, except for the XDP_TX and
XDP_REDIRECT frames. These share the SQs, but bypass the qdisc and are
sent even when the queue is stopped, so BQL can't hold them back.
Counting them would let sustained XDP traffic keep the queue stopped,
starving the stack, and the TX watchdog would then either fire while the
completions still arrive, or, if the XDP sends refreshed trans_start,
not fire when the completions stop. The XDP SKBs are marked in their
skb->cb, next to the WQE size, so that their completions are skipped as
well.
Reset the BQL state when destroying the queues, once their NAPI is
disabled, since the SKBs still pending after a drain timeout are freed
without being completed.
Lost TX completions can now stop a queue sooner: it also stops when the
bytes in flight exceed the BQL limit, not only when the SQ is full, and
the limit may never grow enough to cover the lost bytes. This includes
the completions skipped by the WARN_ON_ONCE() early returns in
mana_poll_tx_cq(), which already leak SQ space: completing the SKBs
already freed there wouldn't reliably balance BQL, since
mana_gd_poll_cq() has already consumed the CQEs of the rest of the
batch. The TX watchdog then fires, as nothing refreshes the trans_start
of a queue stopped by BQL, and its handler resets the queues along with
their BQL state. The exception, as before this patch, is XDP traffic
keeping the SQ full: each XDP send then stops the queue again,
refreshing its trans_start.
Tested on two Standard_D16ds_v6 Azure VMs in a proximity placement
group, where the throughput is capped at 10.6 Gbps, with the DUT
alternately booting net-next (c1c1f0a31712) with and without this patch
applied.
The throughput stays at the cap with 1, 8 and 64 TCP flows, and the idle
TCP_RR latency doesn't change (p50 of 47 us with vs. without the patch).
With 16 senders of 64-byte UDP packets, the DUT sends 3.7 to 4.0 Mpps
without the patch and 3.7 to 4.1 Mpps with it. With bulk TCP flows
sharing the queues, the netperf TCP_RR latency drops (medians of 6
runs):
16 queues, 64 flows: p50 4649 -> 2182 us, p99 5621 -> 2677 us
1 queue, 8 flows: p50 2554 -> 418 us, p99 2723 -> 624 us
The standing queue moves from the SQs to fq_codel, which now drops
packets: about 2500 qdisc drops and 88K TCP retransmissions per 48 s run
with 64 flows, against at most 29 retransmissions before. The
retransmissions are about 0.2% of the segments sent. The TCP_RR flows
lose no packets, and the packets of the bulk flows are dropped before
they reach the wire, so the goodput changes by less than 0.01%.
Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20261013214937.145312-1-hamzamahfooz@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The old test_bpf module is going away, therefore port the two test
cases which were added in 76db8087c4c9 ("net: bpf: add a test for
skb_segment in test_bpf module") as well as cf204a718357 ("bpf,
testing: Introduce 'gso_linear_no_head_frag' skb_segment test")
into the net_test.c to retain coverage. With it in place:
# Subtest: gso_test_func
ok 1 no_gso
ok 2 linear
ok 3 frags
ok 4 frags_pure
ok 5 gso_partial
ok 6 frag_list
ok 7 frag_list_pure
ok 8 frag_list_non_uniform
ok 9 frag_list_head_frag
ok 10 frag_list_no_head_frag
ok 11 gso_by_frags
ok 12 resegment
ok 13 resegment_multi
ok 14 resegment_tail
ok 15 resegment_one_mss
# gso_test_func: pass:15 fail:0 skip:0 total:15
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Willem de Bruijn <willemb@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20261015151033.591439-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
marvell_config_intr() rewrites the whole interrupt enable register, so
the config_intr call from phy_init_hw() on resume silently cleared
WOL_EIE on the 88E1318S and 88E1510: m88e1318_get_wol() still reported
WAKE_MAGIC, but a matched magic packet was no longer routed to INTn and
the board did not wake.
Bit 7 of that register is WOL_EIE only on these two PHYs; on others,
such as the 88E1111, it enables a FIFO error interrupt. So give the
88E1318S and 88E1510 their own config_intr and handle_interrupt, and
leave the shared callbacks unchanged.
m88e1318_set_wol() now records whether WoL is enabled, and both it and
the new config_intr derive WOL_EIE from that state under the MDIO bus
lock. WOL_EIE stays set across config_intr while WoL is enabled, except
when the PHY has an interrupt line and interrupts are being disabled,
as in phy_free_interrupt(): INTn is then the PHY IRQ, and nothing would
read IEVENT after free_irq() to release it. The bit is set again once
interrupts are re-enabled. phy_probe() still clears a WOL_EIE left by a
previous boot, since WoL starts out disabled. The new handler also
claims WoL events, so they do not go unacknowledged when the PHY IRQ is
in use.
Helios4 (Armada 388, 88E1512), 7.2.9. With this patch WOL_EIE stays set
over 3 link down/up cycles, "wol d" clears it, and a magic packet on a
running board is a handled interrupt. Without it, WOL_EIE is lost on the
first down/up, survives "wol d", and the magic packet is an unhandled
interrupt.
Fixes: 3871c3876f80 ("mv643xx_eth with 88E1318S: support Wake on LAN")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Tested-by: Igor Velkov <iav@iav.lv>
Link: https://patch.msgid.link/20261014194818.11640-2-rosenp@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The fan worker changes the direction of both GPIOs and schedules its
next run. Its managed cancellation action is registered before the GPIOs
are acquired, so devres releases the GPIOs before cancelling the work. A
running worker can therefore change a GPIO after the driver has released
it.
Register the work cancellation action after both GPIO acquisitions. This
makes devres cancel and drain the worker before releasing either GPIO.
No work has been queued yet if GPIO acquisition or action registration
fails.
This issue was identified as part of our ongoing research while
reviewing kernel code.
Fixes: b82a7b018b93 ("platform/x86: gpd pocket fan: Clean-up by using managed work init")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/179229442299.3956787.17526066623947466315.gpd-pocket-fan@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
rt6_insert_exception() and rt6_remove_exception() update
rt6_stats->fib_rt_cache of dev_net(rt6i->dst.dev), but the device of an
exception dst can move to another netns while the exception is still in
its bucket.
This happens when the bucket is flushed from an RCU callback, for
instance from nexthop_free_rcu() for the nh_info of a replaced nexthop,
whose exceptions still point to live routes. If the device moves to
another netns before that callback runs, the decrement hits the other
netns, whose u32 counter underflows in /proc/net/rt6_stats, while the
counter of the original netns never goes back down.
Account exceptions to the netns their dst was allocated in, derived from
dst->ops as ip6_dst_gc() already does, which does not depend on the
device. The dst already relies on that netns' ip6_dst_ops being alive
when it is destroyed, which happens after the exception is removed.
Fixes: 81eb8447daae ("ipv6: take care of rt6_stats")
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20261016091556.2750902-1-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cpu feature updates from Borislav Petkov:
- Rework early CPU features detection code to handle a case
where recorded CPU capabilities are temporarily cleared in
an interruptible region.
The practical implication of this lead to, for example, KASAN
complaining due to 5-level pagetable support disappearing
intermittently (Ihor Solodrai)
- AMD Zen5 started reporting TLB sizes as multiples of 32 so adjust
the TLB sizes reporting code to consider that
- Return the proper retval when trying to enable user shadow stacks
* tag 'x86_cpu_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/cpu: Don't transiently clear the boot CPU's capabilities
x86/cpu: Move 32-bit SEP setup into identify_cpu()
x86/cpu: Inline generic_identify() into identify_cpu()
x86/cpu: Initialize boot CPU cpuinfo defaults early
x86/cpu: Factor init_cpu_info() out of identify_cpu()
x86/CPU/AMD: Fix Zen5 TLB sizes reporting
x86/shstk: Return the correct error value when user shadow stacks are disabled
|
|
The RX walk in axienet_dma_bd_release() stops at the first descriptor
without an skb, assuming that such a slot and all after it were never
filled. That holds on the axienet_dma_bd_init() error path, but not once
the ring has been running: when axienet_rx_poll() fails to allocate or
map a replacement buffer it leaves the slot it emptied with a NULL skb,
in the middle of a populated ring, until a later poll refills it.
Closing the interface before then leaks the skb and the streaming DMA
mapping of every descriptor after that slot, which can be most of the
ring, and is most likely under memory pressure.
The walk also frees each skb before unmapping it. With swiotlb, the
DMA_FROM_DEVICE unmap copies the bounce buffer back into the skb data
that was just freed, and on non-coherent platforms it invalidates cache
lines that may already belong to a new owner.
Skip empty slots instead of stopping at the first one. An emptied slot
still has a non-zero cntrl but its buffer is already unmapped, so the
skip has to cover the unmap too, which it does by coming before it.
Then unmap before freeing, as axienet_rx_poll() does.
This was reported by the Sashiko AI review bot.
Tested on the AXI Ethernet MAC of an ADVA TimeCard X2 (PCIe card, with
the built-in AXI DMA): traffic passes after each of ten down/up cycles,
each running axienet_dma_bd_release(), so the unmap-then-free order is
exercised on every buffer. A failed RX refill was not reproduced, so
the skip over an empty slot was not exercised.
Fixes: f26667a373f3 ("net: axienet: Fix DMA descriptor cleanup path")
Fixes: 7a7d340ba4d9 ("net: axienet: fix RX ring refill allocation failure handling")
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
Link: https://patch.msgid.link/20261015084743.1798326-1-maimon.sagi@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Root Port recovery may race with a device hot-unplug. In that case,
dw_pcie_wait_for_link() returns -ENODEV because no device is detected
after the controller has been successfully reset.
This is a valid outcome and should not cause Root Port recovery to
fail. Ignore -ENODEV while continuing to propagate other link-training
errors.
Fixes: 4d88cb82a6d9 ("PCI: qcom: Implement .reset_root_port() and use for link down")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Link: https://patch.msgid.link/20260916-topic-pcie_portrec_enodev-v1-1-5dc7bde39552@oss.qualcomm.com
Assisted-by: LLM
|
|
Fbdev and its drivers use FB_BLANK constants for controlling the
display's blanking state. Semantics differ to similar VESA blanking
constants.
Replace the VESA constant in xilinxfb with FB_BLANK.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fbdev and its drivers use FB_BLANK constants for controlling the
display's blanking state. Semantics differ to similar VESA blanking
constants.
Replace the VESA constants with FB_BLANK in platinumfb. The VESA
constants can be interpreted bitwise, while the FB_BLANK constants
can not. Therefore turn the bit tests in an if-else sequence that
handles the individual cases. By default, the display is unblanked.
The modified code is within a comment block, so it will not run. I
still changed it to keep the driver up to standard. This might also
resolve the nearby TODO comment on incorrect hardware blanking.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fbdev and its drivers use FB_BLANK constants for controlling the
display's blanking state. Semantics differ to similar VESA blanking
constants.
Remove the comment on VESA constants from sa1100fb. It's misleading at
best, as the driver should never use the VESA constants for blanking.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fbdev and its drivers use FB_BLANK constants for controlling the
display's blanking state. Semantics differ to similar VESA blanking
constants.
Replace the VESA constant in i810fb with FB_BLANK.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Fbdev and its drivers use FB_BLANK constants for controlling the
display's blanking state. Semantics differ to similar VESA blanking
constants.
Replace the VESA constants in au1100fb with FB_BLANK.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
qcom_pcie_ep_probe() initializes the DesignWare PCIe endpoint with
dw_pcie_ep_init(). The probe failure paths call dw_pcie_ep_deinit() to
release the corresponding endpoint resources, but the remove path does
not perform the matching teardown after a successful probe.
As a result, resources initialized by the DesignWare endpoint core can
remain allocated when the endpoint controller is removed.
Notify endpoint functions about EPC deinitialization and call
dw_pcie_ep_deinit() before disabling the controller resources. Keep the
existing early return when the link is already disabled since Qualcomm
endpoint controllers depend on the host refclk for hardware cleanup.
This issue was found by manual code inspection.
Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260916090126.2963064-1-lgs201920130244@gmail.com
|
|
Adds Tunable table for XBOX ROG Ally X 20.
Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
Link: https://patch.msgid.link/20261018160603.65449-1-derekjohn.clark@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
|
|
fbcon_rotate_font() records the font, its geometry and the rotation in
par->rotated before calling font_data_rotate(). If the allocation
fails, the error path clears par->rotated.buf, but the recorded key
already looks up to date, so the next call takes the early-out and
never retries. The rotated putcs/cursor ops keep returning early on
the NULL buffer, and the console stays blank even after memory is
available again.
Also test par->rotated.buf in the early-out, so a failed allocation
is retried on the next call: at the next fbcon_switch(),
fbcon_modechanged() or font change.
Fixes: e4ef723d8975 ("fbcon: Avoid OOB font access if console rotation fails")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fbcon_rotate_font() caches a rotated copy of the console font in
par->rotated.buf. The buffer is sized from the font's width, height
and charcount, and is rebuilt in fbcon_init(), fbcon_switch() and
fbcon_modechanged(), but not in fbcon_do_set_font().
When the font is changed through KDFONTOP, the new geometry is
installed and vc_resize() redraws before the buffer is rebuilt. The
rotated putcs/cursor ops then index the old buffer with the new cell
size; KASAN reports a slab-out-of-bounds read in soft_cursor().
Rebuild the buffer for the visible console before the redraw, as the
other callers do: select the console's blitting state with
set_blitting_type() (which also uploads the new font's map on
tile-blitting hardware), then rebuild. Background consoles keep
their rebuild at fbcon_switch() time, as the buffer is shared per
framebuffer and must not be updated for a console that is not being
displayed.
To ensure a correct rollback when the rebuild or the following
vc_resize() fails, save the rotated font state, clear it before
rebuilding, and restore it in the error path of
fbcon_do_set_font().
Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
fbcon_rotate_font() caches a rotated copy of the console font and
skips the rebuild when the fontdata pointer and the rotation match.
Raw font data carries no geometry, though: width, height and
charcount live in vc->vc_font. fbcon_set_font() deduplicates uploads
by byte equality, so the same bytes re-uploaded with different
dimensions keep the fontdata pointer while the geometry changes, and
the early-out skips the rebuild.
The rotated cell size depends on the geometry (rotation swaps width
and height), so the stale buffer is indexed with the new cell size.
Re-uploading a 4x16 font as 16x8 on a CW-rotated console, for
example, doubles the rotated cell size and reads past the end of the
old buffer.
Record the geometry the buffer was built from and compare it in the
early-out. The pointer-only key used to be backed by an explicit
width check in the deduplication, which commit 1e3c49aa03fb
("lib/fonts: Compare font data for equality with font_data_is_equal()")
dropped.
Fixes: 6cc50e1c5b57 ("[PATCH] fbcon: Console Rotation - Add support to rotate font bitmap")
Cc: stable@vger.kernel.org
Signed-off-by: Yao Yiqi <yaoyiqi3@huawei.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
Commit 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix
vmalloc-out-of-bounds") made bit_putcs() clip glyphs to var.yres. When
fbcon scrolls by panning, it draws text rows up to var.yres_virtual,
so after the first pan most new text is not drawn until the next full
redraw. This affects fbdev drivers that set FBINFO_HWACCEL_YPAN or
FBINFO_HWACCEL_YWRAP, such as vesafb with the ypan option, when
CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y.
Clip to GETVYRES() instead, which fbcon_ud.c and fbcon_ccw.c already
use as the drawing area height. When fbcon does not pan, GETVYRES()
returns var.yres, keeping the existing bound. When fbcon pans, it
returns var.yres_virtual, which the framebuffer memory must cover
anyway for panning to work.
Fixes: 3637d34b35b2 ("fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds")
Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
Closes: https://lore.kernel.org/linux-fbdev/b8b52ffd-ecec-4fba-b432-ba32135c2f99@suse.de/
Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Tingjie Zhong <catme0w@live.cn>
Signed-off-by: Helge Deller <deller@gmx.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 cleanups from Borislav Petkov:
- The usual pile of cleanups all over the place
* tag 'x86_cleanups_for_v7.4_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/asm: Remove CR4 read fault handler
x86/um: Remove unused <asm/required-features.h> header
x86/cpu: Constify struct x86_cpu_id
x86/asm/string_64: Remove unused linux/jump_label.h include
x86/mtrr: Fix kernel-doc notation of amd_set_mtrr()
|
|
net_devmem_bind_dmabuf() uses dma_buf_attach(), a static attachment
with peer2peer false. Exporters must then keep the buffer reachable
without P2P; amdgpu does so by placing it in GTT (system memory), so a
device memory binding silently ends up in host memory.
Use dma_buf_dynamic_attach() with allow_peer2peer set, so an exporter
that can do P2P to the device keeps the buffer in device memory.
Dynamic attachments are not pinned on map, and devmem cannot handle the
buffer moving, so:
- pin it with dma_buf_pin() before mapping, which keeps it in place for
the lifetime of the binding, as before;
- wait for the exporter's kernel fences after mapping, interruptibly,
as the core does for static attachments.
This follows the pinned RDMA umem path, including its limits: the
binding cannot be revoked by the exporter, and once a P2P binding has
pinned a buffer in device memory, a later attachment to the same buffer
that cannot do P2P may fail to pin it. Exporters that cannot do P2P to
the device place the buffer as before. RX and TX bindings both go
through this function.
Signed-off-by: Erfan Sharafzadeh <erfansh@meta.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20261013210954.2170175-1-erfansh@meta.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
fix_alignment() already reads the instruction with
copy_inst_from_kernel_nofault() when the PC is a kernel address, and
only uses __get_user_instr() when it is not. That pointer is an
ordinary user address, so read it with get_user_instr(). On powerpc
__get_user() already does might_fault() and opens user access for the
read itself, so the only difference is the address check.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
setup_trampoline() writes the seven words of the on-stack sigreturn
trampoline with __put_user(), relying on the frame having been checked
when the frame setup opened its user write access. It is called after
that access has been closed again, so each of the seven writes opens and
closes user access on its own.
Write them inside one scoped_user_write_access_size() covering the
whole trampoline instead. Everything in it is a store, so a write-only
window is enough, and the instruction cache flush stays outside it.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
swapcontext and rt_sigreturn read the signal mask with
__get_user_sigset(), and rt_sigreturn also reads the MSR and uc_link
words of the transactional-memory path, each with one __get_user()
after an access_ok() on the whole context.
Make the helper get_user_sigset(), built on get_user(), and use
get_user() for the other two. On powerpc __get_user() already does
might_fault() and opens user access for the read itself, so the only
difference is the address check, which these pointers pass anyway.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
A few places in the 32-bit and compat signal code read a single field
with __get_user(): the uc_regs and MSR words in swapcontext and the
transactional-memory sigreturn and setcontext paths, and uc_link in
rt_sigreturn. They are not part of a run of accesses, and either rely
on an earlier access_ok() or on compat pointers being below 4GB.
Use get_user(). On powerpc __get_user() already does might_fault() and
opens user access for the read itself, so the only difference is the
address check, which these pointers pass anyway.
This is part of getting rid of __get_user() and __put_user() entirely.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
