Replace the warning and file permission change with an error when an
"unsafe" net sysctl registration is detected.
One of the barriers preventing the const qualification of the ctl_tables
in the net directory is the permission (->mode) change in
ensure_safe_net_sysctl. This prep commit removes that barrier and
ensures that the received ctl_table pointer to the net ctl_table
register function is const.
Signed-off-by: Joel Granados <joel.granados@kernel.org>
Link: https://patch.msgid.link/20260810-jag-net_const_qualify-v4-1-77e888237c69@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The commit that introduced the receive-path latency trace added the
clearing of inc->i_rx_lat_trace[] to rds_inc_init() only;
rds_inc_path_init() never got it.
That asymmetry matters for the one caller that reuses memory:
rds_tcp_data_recv() carves its rds_tcp_incoming out of a kmem_cache
with no zeroing and no constructor, so after rds_inc_path_init() the
array still holds the timestamps of whatever message previously
occupied that slab object. No stale value is user-visible today -
every message that reaches the socket happens to overwrite all four
slots (RX_HDR at allocation, RX_START when the header completes,
RX_END at delivery, RX_CMSG at recvmsg time) before
RDS_CMSG_RXPATH_LATENCY reads them back as deltas - but that is a
property of the current writers, not of the init contract, and a
future trace point or an early-exit path would expose another
message's timestamps to userspace.
Clear the array in rds_inc_path_init() too, so both init helpers
leave the inc fully initialized. memset is the form the clearing
already takes on the rds_inc_init() side since commit 1635bb548f
("net: rds: use memset to optimize the recv"). Hardening only; no
user-visible bug in the current code.
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260810055631.299558-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Allison Henderson says:
====================
net/rds: Bug fix ports, part 2
This is the next batch of net/rds fixes ported from the Oracle UEK
kernel, following up on the first set now in net-next [1].
This is v2 of patches 1 and 2 of "net/rds: Bug fix ports, part 2"
[2], which contained two initialization-hardening ports. While
re-reviewing v1's patches 3 and 4 (the fastpath-lock teardown changes)
I found their locking needs more rework than a respin should carry, so
they are split out and will return as their own series together with
two companion fixes. The two patches here are independent of them.
[PATCH net 1/2] net/rds: reinitialize to_be_dropped on rds_send_xmit() restart
Port commit 7f52b9968d79 ("net/rds: rds_send_xmit should INIT_LIST_HEAD (&to_be_dropped) on restart")
7f52b9968d
[PATCH net 2/2] net/rds: initialize i_conn_path in rds_inc_init()
Port commit 0ec6a520da4f ("rds: rds_inc_init() should initialize the inc->i_conn_path field")
0ec6a520da
Questions and comments appreciated!
====================
Link: https://patch.msgid.link/20260809005103.82371-1-achender@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rds_inc_init() initializes every field of the embedded rds_incoming
except i_conn_path, and incomings are not zero-allocated (IB carves
them out of a slab cache). The field therefore holds stale garbage
for incs created by rds_ib.
The loopback transport is different: rds_loop_xmit() re-runs
rds_inc_init() on the message's embedded inc after
rds_send_queue_rm() has already stored the connection path in it, so
there the field holds a live value rather than garbage, and a NULL
store would discard it. Switch rds_loop_xmit() to
rds_inc_path_init() with the connection's single path, which is
exactly the value readers of the field reconstruct for a
non-multipath transport.
With loopback preserving the field, initialize it to NULL in
rds_inc_init() so that any future reader trips over a clean NULL
pointer instead of a stale one, and so the two init helpers
(rds_inc_init/rds_inc_path_init) leave the structure in an
equivalent, fully-initialized state. Hardening only; no reader
dereferences i_conn_path for a non-multipath transport today.
This mirrors Oracle UEK commit "rds: rds_inc_init() should initialize
the inc->i_conn_path field".
Signed-off-by: William Kucharski <william.kucharski@oracle.com>
[achender: port to net-next; keep loopback's i_conn_path valid by
switching rds_loop_xmit() to rds_inc_path_init(); update commit
message]
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260809005103.82371-3-achender@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The to_be_dropped list is declared once at the top of rds_send_xmit()
but the function can loop via "goto restart" after each batch. The
code currently relies on rds_send_remove_from_sock() having emptied
the list entry by entry (via list_del_init()) at the end of the
previous batch; nothing in rds_send_xmit() itself guarantees the list
head is empty when a new batch starts.
Re-initialize the list on every restart, and warn once if it is ever
found non-empty there: entries left on the list at that point would
keep their message reference, their RDS_MSG_ON_SOCK accounting and
their pending RDS_RDMA_DROPPED notification, so a silent re-init
would orphan them. This is hardening: no user-visible bug is known
in the current code.
This mirrors Oracle UEK commit "net/rds: rds_send_xmit should
INIT_LIST_HEAD(&to_be_dropped) on restart".
Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
Signed-off-by: Sharath Srinivasan <sharath.srinivasan@oracle.com>
[achender: port to net-next (keep the existing LIST_HEAD declaration and
add only the restart re-init); warn if the restart invariant is
violated; update commit message]
Assisted-by: Claude-Code:claude-fable-5
Signed-off-by: Allison Henderson <achender@kernel.org>
Link: https://patch.msgid.link/20260809005103.82371-2-achender@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
xs_init() registers xs_reboot_nb before initializing XenStore
communications and starting xenwatch. If either operation fails, the
notifier remains registered and a later initialization attempt can hit a
duplicate registration.
Check the notifier registration result and unregister it on every
subsequent failure path.
Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent xenstore accesses")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Message-ID: <20260807032326.940377-1-dbgh9129@gmail.com>
When testing a linux-next kernel with commit 59bd1d914b ("memblock:
warn when freeing reserved memory before memory map is initialized"),
the following warning was hit when there was a "nohz_full" kernel boot
parameter.
Cannot free reserved memory because of deferred initialization of the memory map
WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0
:
Call Trace:
<TASK>
memblock_phys_free+0xcb/0x100
housekeeping_init+0x14c/0x170
start_kernel+0x207/0x450
x86_64_start_reservations+0x24/0x30
x86_64_start_kernel+0xda/0xe0
common_startup_64+0x13e/0x141
</TASK>
IOW, we shouldn't free memblock allocated memory so early
in the boot process when memory map isn't fully initialized in
deferred_init_memmap().
Fix it by saving the housekeeping cpumask memblock memory to be
freed into a llist free list in housekeeping_init() and add a new
housekeeping_late_init() helper to defer the actual freeing of memblock
memory to when initcall's are being processed. The cpumask memblock
memory is treated as a llist_node with the size of a "long" type which
is also smallest cpumask size that can be allocated.
The non-atomic version of the llist APIs are used as there is no
contention.
This commit depends on the presence of commit 7c2eee9c13 ("memblock:
don't touch memblock arrays when memblock_free() is called late")
to prevent a KASAN UAF bug report [1].
[1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/
Fixes: 27c3a5967f ("sched/isolation: Convert housekeeping cpumasks to rcu pointers")
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Link: https://patch.msgid.link/20260701195810.477326-1-longman@redhat.com
Yuyang Huang says:
====================
ipv6: report why a route was deleted in RTM_DELROUTE
When the kernel deletes an IPv6 route on its own, the RTM_DELROUTE
notification does not say why. User space cannot tell a route that
expired from one the router explicitly withdrew, yet the two call for
different reactions: an expired RA route means the router failed to
refresh it in time, which points at a misconfigured or unreliable
router and may warrant action such as disabling IPv6 on that network,
while a zero-lifetime withdrawal is normal, RFC-compliant operation.
This is a general problem for any consumer device running Linux,
especially on Wi-Fi networks, where multicast delivery is not
guaranteed (e.g. frames can be lost around DTIM for clients in power
save mode). The motivating case is Android: the userspace NetworkStack
process listens on RTMGRP_IPV6_ROUTE and today treats any loss of the
IPv6 default route as "router lost". To avoid the device repeatedly
gaining and losing IPv6 connectivity on a badly configured network,
when it detects the device is on a dual-stack network with working
IPv4 connectivity, it defensively clears accept_ra_defrtr and restarts
IPv6, so user space apps stop using broken global IPv6 connectivity
while link-local IPv6 keeps working. That reaction is wrong if the
route was withdrawn by a zero-lifetime RA (some ISPs do this
intentionally for reconfiguration) - with accept_ra_defrtr off, IPv6
never recovers once the router advertises again. It is the right
reaction if the route genuinely expired, since the router failed to
refresh it in time.
Fixing this in user space is not practical: RTM_NEWROUTE carries the
initial route lifetime (in rta_cacheinfo), but the kernel does not
resend it when a later RA refreshes the lifetime. So distinguishing
the cause of an RTM_DELROUTE from user space would mean opening a raw
socket, listening to RAs, and tracking lifetimes independently,
duplicating logic the kernel already has. Sending RTM_NEWROUTE on
every RA lifetime refresh was also considered, but that would be
spammy and is technically wrong, since a lifetime update does not add
a new route.
This series proposes RTA_DEL_REASON instead: it tells user space why
the route was deleted so it can react accordingly. In the Android
case, NetworkStack would defensively disable global IPv6 only on
RT_DEL_REASON_EXPIRED, and take no action on
RT_DEL_REASON_RA_WITHDRAWN, since that is RFC-compliant behavior.
Patches 1 to 6 add RTA_DEL_REASON and enum rt_del_reason to the
rtnetlink uAPI, thread the reason from the kernel-initiated IPv6
deletion paths down to the RTM_DELROUTE notification, and record the
cause: RT_DEL_REASON_EXPIRED for routes garbage collected after their
RTF_EXPIRES lifetime ran out, and RT_DEL_REASON_RA_WITHDRAWN for
default routes, prefix routes and RFC 4191 route information routes
withdrawn by Router Advertisements. Patches 1 to 5 are no-ops on the
wire; the attribute first appears in patch 6. The route addition path
is not touched.
Patches 7 to 9 extend the rt-route Netlink spec with the route
notifications and their multicast groups, split the newroute and
delroute request attribute lists out of the shared getroute reply
list, and add the new attribute and its enum.
Only kernel-initiated deletions that user space cannot otherwise
explain are attributed. User-requested deletions are self-explanatory
to the requester, so they carry no reason; the UAPI documents that
absence and RT_DEL_REASON_UNSPEC must be treated identically, which
keeps the door open for attributing more paths (nexthop removal
cascades, device removal) later.
Patch 10 adds selftests covering all three producer paths: a
GC-expired route, and a default route + PIO prefix route + RIO route
advertised and then withdrawn by hand-crafted RAs over a raw ICMPv6
socket (no external RA tool needed), plus a check that user-requested
deletions carry no attribute. The notifications are decoded with YNL,
which also exercises the rt-route spec additions.
====================
Link: https://patch.msgid.link/20260808005642.26901-1-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Extend rtnetlink.py to check the reason reported in RTM_DELROUTE:
- expired: route with a 2s lifetime collected by the fib6 GC
(gc_interval lowered like fib_tests.sh fib6_gc_test does);
- ra-withdrawn: a single RA advertises a default route (router
lifetime), an on-link prefix route (RFC 4861 prefix information
option) and a route information option route (RFC 4191), then a
second RA withdraws all three with zero lifetimes; the RAs are
crafted over a raw ICMPv6 socket so the test does not depend on an
external RA tool;
- absence: a userspace deletion request records no cause and must not
carry the attribute at all.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-11-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the del-reason attribute and its enum to the route attribute set,
and to the getroute reply, which the route notifications reuse.
The attribute is absent from the newroute and delroute request lists.
RTA_DEL_REASON is above strict_start_type in rtm_ipv6_policy, so
encoding it in a request is rejected with -EINVAL.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-10-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The newroute and delroute requests alias the same attribute list as the
getroute reply, but requests and replies do not carry the same
attributes. Give the requests their own list.
The two lists are identical today, so the generated code does not
change.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-9-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Declare the RTM_NEWROUTE and RTM_DELROUTE notifications and the route
multicast groups, so that generated clients can subscribe to route
changes. Both notifications reuse the getroute reply attributes.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Link: https://patch.msgid.link/20260808005642.26901-8-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move the body of inet6_rt_notify() to __inet6_rt_notify() and give it
the deletion reason. inet6_rt_notify() keeps its prototype, so the
route addition path does not change.
Add inet6_rt_del_notify() and call it from fib6_del_route().
RTA_DEL_REASON now reaches user space on RTM_DELROUTE for routes the
kernel deleted on its own.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-7-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Emit RTA_DEL_REASON from rt6_fill_node() when the deletion reason is
not RT_DEL_REASON_UNSPEC, and reserve room for it in
rt6_nlmsg_size().
Every caller still passes RT_DEL_REASON_UNSPEC.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-6-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the deletion reason to rt6_fill_node() so that it can report it to
user space. All callers pass RT_DEL_REASON_UNSPEC for now.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-5-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Record why the kernel deletes an IPv6 route on its own:
- RT_DEL_REASON_EXPIRED for routes reaped by the FIB6 garbage
collector after their RTF_EXPIRES lifetime ran out.
- RT_DEL_REASON_RA_WITHDRAWN for default routes, prefix routes and
RFC 4191 route information routes withdrawn by a zero-lifetime
Router Advertisement.
Deleting a default route because its metric changed is not a
withdrawal, so it keeps RT_DEL_REASON_UNSPEC.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-4-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Pass the deletion reason from ip6_del_rt_reason() down through
__ip6_del_rt(), fib6_del() and into fib6_del_route(). All existing
callers pass RT_DEL_REASON_UNSPEC.
fib6_del_route() ignores the reason until the notification path learns
to report it.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-3-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add RTA_DEL_REASON and enum rt_del_reason to the rtnetlink uAPI, and
add ip6_del_rt_reason(), which takes the reason a route is being
deleted. It has no skip_notify argument: a caller that records a
deletion reason wants the notification that carries it.
The reason is unused for now. Subsequent patches propagate it to the
deletion path and report it on RTM_DELROUTE.
Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260808005642.26901-2-sigefriedhyy@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In timens_separate and pidns_separate both the child and the grandchild
write a 'Y' readiness byte to the same pipe, but the parent expects a
single 'Y' followed by the grandchild's pid. If the grandchild's byte
arrives first, the parent takes it for the child's and reads the pid
misaligned, ending up with a garbage value.
The parent stores that pid in self->grandchild_pid so that
FIXTURE_TEARDOWN() can kill the grandchild. A garbage pid leaves the real
grandchild alive in pause(), holding the test runner's TAP pipe open and
hanging the whole collection.
The grandchild has nothing to report, so drop its write() and leave the
child as the sole writer.
Fixes: fdb48976b6 ("selftests/namespaces: Kill grandchild in nsid fixture teardown")
Signed-off-by: Ricardo B. Marlière (SUSE) <ricardo@marliere.net>
Link: https://patch.msgid.link/20260810-selftests-namespaces_race-v1-1-4307e833783e@marliere.net
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
pipe->poll_usage was added to ensure that edge-triggered epoll consumers
get a wakeup on every write, even if the pipe was already non-empty.
However, none of the existing epoll_wakeup_test cases cover this; the
test suite passes even with WRITE_ONCE(pipe->poll_usage, true) removed.
Add a test that writes twice to a pipe and verifies that epoll_wait with
EPOLLET reports data each time. This covers the pipe-specific per-write
wakeup behavior that edge-triggered consumers depend on.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: https://patch.msgid.link/amnlGZesXu-SUK2H@redhat.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Like commit 98f256e272 ("rust: doctest: add LocalModule fallback
for #[vtable] ThisModule"), add another `LocalModule` struct with a
null-pointer `ModuleMetadata` `impl` for the `kernel` crate, so that
`crate::LocalModule` (auto-inserted by `#[vtable]`) resolves correctly
when there is no `module!` macro.
This will be needed by DRM to use `#[vtable]` `impl` blocks in KUnit
tests within the `kernel` crate [1].
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/rust-for-linux/DKNAS52KYWLD.M15VEC6U0F6R@kernel.org/ [1]
[ Created commit out of the diff in the link above. Fixed the
`clippy::undocumented_unsafe_blocks` lint by wrapping with a block
like in the other commit too. Added `#[allow(dead_code)]` until we
actually (and unconditionally, i.e. KUnit tests may be not enabled)
use it. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state
(pd->tunnel and pd->session) is kept in seq_file private data to allow
iteration across multiple read() system calls.
However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels
before reading to end-of-file (EOF), any tunnel or session reference stored in
pd->tunnel / pd->session is left un-dropped when seq_file private data is freed.
Fix this by dropping any remaining pd->tunnel and pd->session references in
pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.
Fixes: 0e0c3fee3a ("l2tp: hold reference on tunnels printed in pppol2tp proc file")
Fixes: f726214d9b ("l2tp: hold reference on tunnels printed in l2tp/tunnels debugfs file")
Reported-by: syzbot+d6fa74e3f19d6ee01e3a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a760f32.01d0871a.3a0d52.004f.GAE@google.com/T/#u
Assisted-by: Jetski:Gemini-3.1-Pro
Cc: James Chapman <jchapman@katalix.com>
Cc: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260811144651.2733424-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
cls_bpf_prog_from_efd() obtained a SCHED_CLS program via
bpf_prog_get_type_dev() but never verified that a device-bound (offloaded)
program's bound netdev matches the TC netdev the classifier is being
attached to. This let a program loaded with prog_ifindex for device A be
attached via cls_bpf + skip_sw to device B; deleting device A then
destroyed the program's offload state while it was still attached to
device B, triggering a netdevsim WARN (panic with panic_on_warn=1).
Mirror the XDP attach path (net/core/dev.c) and reject the attach with
-EINVAL when a dev-bound program's bound device does not match the
target device.
Fixes: 2b3486bc2d ("bpf: Introduce device-bound XDP programs")
Reported-by: vega@nebusec.ai
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/20260809094418.901607-1-jhs@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The HP 250 G8 Laptop PC (subsystem 103c:85f3) using the Realtek ALC236
codec requires a specific quirk to enable the mute button LED.
Currently, the audio mutes in software, but the physical indicator
light remains unlit.
Adding a quirk entry to the alc236_fixup_tbl with the
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup correctly maps the
LED to the mute state via COEF index 0x07.
Signed-off-by: Bramwel Barack <bramwelbarack89@gmail.com>
Link: https://patch.msgid.link/20260812192832.69240-1-bramwelbarack89@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Running vector workloads like perf + mcf on KVM can result in an
unexpected termination due to a vtype corruption. This happens because
the kernel-mode vector (KMV) misattributes the guest's vcpu context as
the user's context and source from a wrong status.VS.
The simplified call chain that results in this problem is shown as
follow:
__riscv_sys_ioctl()
kvm_arch_vcpu_ioctl_run()
kvm_riscv_vcpu_exit()
kvm_riscv_vcpu_sbi_ecall()
kvm_riscv_vcpu_pmu_ctr_stop()
kvm_vcpu_write_guest()
__copy_to_user()
enter_vector_usercopy()
kernel_vector_begin()
kernel_vector_begin() should use the sstatus.VS from guest's vcpu
context instead of task_pt_reg(current). Also, it should not save
guest's v-reg into the user's context memory.
To resolve this, the vcpu context must be correctly saved when KMV is
serving a guest. However, invoking KVM functions directly from generic
RISC-V architecture code introduces a reverse dependency, breaking
builds when KVM is configured as N or M.
Address this by registering an RCU-protected callback for context
flushing. KVM registers this callback at module initialization and
unregisters it on exit. When KMV starts a kernel context, it can now
safely flush the vector context via the callback.
Fixes: ecd2ada8a5 ("riscv: Add support for kernel mode vector")
Signed-off-by: Andy Chiu <tchiu@tenstorrent.com>
Reviewed-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260803215250.824417-4-tchiu@tenstorrent.com
Signed-off-by: Anup Patel <anup@brainfault.org>
Similar to commit 7137a203b2 ("arm64/fpsimd: Permit kernel mode NEON
with IRQs off"), we are upgrading get/put_cpu_vector_context such that
kvm_arch_vcpu_load/put can be safely called under both irq off and
regular process context.
Also, export both symbols so the kvm module can call into it.
Signed-off-by: Andy Chiu <tchiu@tenstorrent.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260803215250.824417-3-tchiu@tenstorrent.com
Signed-off-by: Anup Patel <anup@brainfault.org>
Refactor riscv_v_start_kernel_context() to drop `is_nested` variable and
simplify the logic.
This introduces no functional change and works as a preparatory patch for
the kernel-mode vector fix.
Signed-off-by: Andy Chiu <tchiu@tenstorrent.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260803215250.824417-2-tchiu@tenstorrent.com
Signed-off-by: Anup Patel <anup@brainfault.org>
snd_hdac_ext_stream_reset() polls PPLCCTL for STRST by masking the
register value with AZX_PPLCCTL_STRST:
val = readl(...) & AZX_PPLCCTL_STRST;
The same masked value is then used when clearing STRST. Since val
contains no bits other than STRST, clearing STRST from it always
produces zero. The subsequent writel() therefore writes zero to the
entire PPLCCTL register instead of clearing only the reset bit.
PPLCCTL contains other stream control fields, including the stream tag
in AZX_PPLCCTL_STRM_MASK. Those fields must not be modified as a side
effect of clearing stream reset.
Use snd_hdac_updatel() to clear STRST, matching the existing set-reset
path and preserving all unrelated PPLCCTL bits.
Fixes: df203a4e46 ("ALSA: hdac_ext: add extended stream capabilities")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/43BB7930B0F07C09+20260813065524.1955696-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Guard guest prefix handling behind `KVM_S390_MANAGES_S390_GUEST`. This
enables other KVM implementations to use gmap without implementing
prefix handling. The prefix handling is integrated deeply in the gmap
implementation. Therefore, provide safe default implementations for the
guarded functions.
No functional changes.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Guard guest CMMA behind `KVM_S390_MANAGES_S390_GUEST`. This enables
other KVM implementations to use gmap without implementing CMMA.
No functional changes.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Guard guest storage key handling behind `KVM_S390_MANAGES_S390_GUEST`.
This enables other KVM implementations to use gmap without implementing
storage key infrastructure. Define KVM_S390_MANAGES_S390_GUEST to 1 for
KVM hosts managing s390 guests (in kvm_host_s390.h). A KVM
implementation not implementing those features must define
KVM_S390_MANAGES_S390_GUEST to 0 in its kvm_host_<guest_arch>.h.
No functional changes besides the new guard.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Refactor gmap code such that a second s390 (host) KVM implementation can
use the gmap code as well. Move mmu code from s390 to gmap so the other
KVM implementation can use it as well.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Move PGM code definitions from kvm_host_s390.h (back) to the generic
kvm_host.h. These definitions are needed by multiple KVM implementations
and should be in a shared location.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Move all the code required to run s390 KVM guests on s390 to a s390
subdirectory. Move gmap related code into a gmap directory to later
share gmap code between KVM implementations.
Update S390 VFIO-PCI MAINTAINERS filepath.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Rename kvm_host.h to kvm_host_s390.h and kvm_host_types.h to
kvm_host_s390_types.h to distinguish s390-specific KVM definitions
from the generic kvm_host.h that will be used for shared definitions.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Rename kvm-s390.c to s390.c and kvm-s390.h to s390.h for consistency
with the new directory structure. Update all include statements and
simplify Makefile ccflags from explicit paths to -I$(src).
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Update include guard names in dat.h, faultin.h, and gmap.h to
ARCH_KVM_GMAP_* to reflect their upcoming relocation to a shared gmap
directory.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Move the kvm_s390_major_guest_pfault trace event from trace.h to a new
trace_gmap.h header. This separates gmap-specific tracing from general
KVM/s390 tracing, preparing for code sharing between multiple KVM
implementations.
The trace event definition is updated to use local defines for
parameters so that they can be replaced later with ease for when another
KVM implementation uses these traces.
No functional change.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
TLB Invalidation by Range has a fairly powerful way of encoding pretty
large ranges in a small number of bits. This range can be based on an
arbitrary VA, which means it is pretty easy for a guest to generate an
overflow should the hypervisor be naive enough to add the range to the
base...
Make sure the range is capped to the limit dictated by the address bit
that determines the VA range. For an IPA invalidation, this is further
corrected down the line to ignore the upper range.
Fixes: 4ffa72ad8f ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
Reported-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://lore.kernel.org/r/yifz3wn5gk5sr6mapi32trgk5m5kp33bquctsjmkifebnsnndt@fix6u4rthx4g
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://patch.msgid.link/20260810170616.746100-1-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
aie2_populate_range() incorrectly failed jobs for BOs with multiple
mmaps: if the unmapped entry appeared first in umap_list, the loop would
pick it up, call hmm_range_fault() on a gone VMA, and return -EFAULT
without ever trying the remaining valid mapps.
Fix it by skipping unmapped entries. After the loop, if the map list is
empty or all maps are valid, map_invalid can be cleared normally.
Fixes: e486147c91 ("accel/amdxdna: Add BO import and export")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260812205628.810816-1-lizhi.hou@amd.com
Under heavy concurrent DMA traffic on CoCo VMs, inc_used_and_hiwater()
performs an atomic_long_add_return() plus a CAS loop on the global
used_hiwater, and dec_used() performs an atomic_long_sub() on total_used.
All CPUs contend on the same cacheline, causing measurable throughput
degradation at scale.
Historically these counters were only compiled in under CONFIG_DEBUG_FS,
which means production kernels with debugfs paid the atomic overhead
unconditionally. Make the tracking boot-time opt-in instead so that it
is disabled by default with near-zero overhead via static_call, and can
be enabled via "swiotlb=track_hiwater" parameter on demand for debugging.
Note that when CONFIG_DEBUG_FS is enabled but hiwater tracking is disabled,
the "io_tlb_used" metric reports an approximate value rather than an
instantaneously exact one.
Suggested-by: Fan Du <fan.du@intel.com>
Signed-off-by: Jun Miao <jun.miao@intel.com>
Co-developed-by: Fan Du <fan.du@intel.com>
Signed-off-by: Fan Du <fan.du@intel.com>
Tested-by: chenhuguanshen <chenhgs@chinatelecom.cn>
Signed-off-by: chenhuguanshen <chenhgs@chinatelecom.cn>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20260812070459.637077-1-frankchen158@126.com
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Add support for the PCIe PMU found on LECARC SoCs.
LECARC platforms use the standard DesignWare PCIe Controller, and the
existing DWC driver already handles the enumeration and basic
functionality through the generic PCIe core.
Hence, add the PCI vendor ID to the vendor-specific capability (VSEC) list,
which enables the standard DWC RAS/DES feature detection.
Signed-off-by: Brett Zhou <brett_zhou@lecomputing.com>
Signed-off-by: Braden Zhang <braden_zhang@lecomputing.com>
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260721-pcie-pmu-v5-1-570e44af7cde@lecomputing.com
Up until now, the MT8173 elm/hana device tree has set the dedicated
regulator supplying the trackpad as always-on, simply because the Elan
driver was missing proper delays. As a result the delay for the
Synaptics trackpad was also omitted, as it was not strictly required
under such a model and delayed the availability of the trackpad to the
user.
The Elan driver recently gained proper delays after power-up, with
adaptive skipping of the delay if the regulator was originally
on. The I2C HID driver and I2C OF component prober library gained
similar adaptive delay skipping. The device tree will be fixed to have
the regulator not be always on, and proper post-power-on delay time
added to the I2C HID device.
Also add the post-power-on delay to the ChromeOS OF component prober,
so that if the regulator is off at the time of probing, the prober knows
to wait for the hardware to initialize.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260811122011.3539250-8-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The commit 7619a0ee93 ("bpf: Mark existing lock-safe kfuncs with KF_SPINLOCK_SAFE")
dropped some helpers in verifier, which also eliminated the use of the
following kfuncs from the special_kfunc_list:
* bpf_arena_reserve_pages
* bpf_stream_vprintk
* bpf_stream_print_stack
So, drop them from the special_kfunc_list.
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
Link: https://lore.kernel.org/bpf/20260812164843.55601-1-leon.hwang@linux.dev
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
The dup/restore of insn_aux_data was introduced to resolve the
inconsistency between insnsi and insn_aux_data arrays, which occurs
on the failure path where insnsi was rolled back to the original
state before constants blinding, while insn_aux_data was not.
After JIT failure, there is only one user, bpf_clear_insn_aux_data(),
that requires insnsi and insn_aux_data to be synchronized. It accesses
both insnsi and insn_aux_data using the same array size and index.
However, the access to insnsi in bpf_clear_insn_aux_data() is not
necessary. It is checked to skip the second slot of an ldimm64 instruction,
whose jt is never set and can be absorbed into the jt check itself.
So remove the access to insnsi from bpf_clear_insn_aux_data(), and add a
specific length field for insn_aux_data to allow it to have a different
length from the insnsi array. Then remove dup/restore of insn_aux_data.
Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/5a4528f019c8d2638c019a2f37475cccc16a9503.1785240296.git.xukuohai@huawei.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
io_import_reg_vec() converts the estimated number of bio_vec entries
into iovec-sized storage when struct bio_vec is larger than struct
iovec. The conversion still multiplies nr_segs by sizeof(struct
bio_vec) in size_t without checking for overflow.
On 32-bit kernels, a registered buffer large enough to make
io_estimate_bvec_size() return 357913942 segments wraps the byte count
from 0x100000008 to 8. io_vec_realloc() then reserves only the input
iovecs plus one extra slot while io_vec_fill_bvec() writes the full
bio_vec array.
Check both the multiplication and the rounding addition before
deriving the replacement iovec count.
Fixes: b4e41050b2 ("io_uring/rsrc: raise registered buffer 1GB limit")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Link: https://patch.msgid.link/20260812203042.720348-1-Jeremy.Jean@oss.cyber.gouv.fr
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- dat: drop non-4addr backwards compatibility, by Sven Eckelmann
- tvlv: handle negative tvlv processing return codes,
by Sven Eckelmann
- improve kernel-doc, add comments and warnings,
by Sven Eckelmann (3 patches)
- coding style: split declarations, reverse x-mas tree,
by Sven Eckelmann (2 patches)
- handle errors in batadv_init(), by Minhong He
- correct NET_RX_* NET_XMIT_* confusion, by Sven Eckelmann
- remove negative returns for batadv_send_skb_unicast,
by Sven Eckelmann
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAmpzRicWHHN3QHNpbW9u
d3VuZGVybGljaC5kZQAKCRChK+OYQpKeoWY0D/9orB3Kwl+xwweViqRT/YDLJa1U
obQSy8NZxhDXIbP2XjN0GBzpxJmqj0VNZCd1OQdRrftNtDCsc4MxjSMbrfLSfyMl
4SxQIN20O9X3/1Ohs3edPSuNgDV2ztHLPlJFWwepYB2oi7ZR9Fvceq5s/bH2b/q/
qzjnjITGehXzwT4NSNNT2ENxQwqNY/Pa761rLVnDQbi5Dqja5BelV/TLVVSXBekI
/fmkeSdzp+a9CuB3cbacXP9obHQ7sbtWmri2FoohS0OiAYy0nMp1+ECEoBOm0N+f
4I943aEWs606gkql0OF0eXGWmrv4LbKSG8exw4fNyorotPMa2OcyUU7u5q6lhhzG
+sVgSTI+sxuNISaOhrOj+bPu9sMGQ+qYwoTsJQ7qTsZFPgR2fGxqHWavdPrb196d
eaO61YsjOQsmhEnxolPISqmFA05Jf0pPk8O2mTctF+77RE3er+j6UkvmuHv45rA3
ijCJBPVmIXJGsv2VweeeE8GPbPKMHZH8IsxvSCMccex0K2Ok/MUx2Ay6T0X3ewPZ
E82Vr27a8hWZpaoPQBrnCxSewj2ewRnt+ifUvi5xLexicmW4KOBecy5ykRM85CH+
N2mZnwuwd7ZGaUw8DFQOXsYkDWLRCh2AKu5oEhekcv+K7QsOsSsqLhz7Jibxx7ua
aMI4XFOZ5bQ2NiampQ==
=LD3V
-----END PGP SIGNATURE-----
Merge tag 'batadv-next-pullrequest-20260805' of https://git.open-mesh.org/batadv
Simon Wunderlich says:
====================
This cleanup patchset includes the following patches:
- dat: drop non-4addr backwards compatibility, by Sven Eckelmann
- tvlv: handle negative tvlv processing return codes,
by Sven Eckelmann
- improve kernel-doc, add comments and warnings,
by Sven Eckelmann (3 patches)
- coding style: split declarations, reverse x-mas tree,
by Sven Eckelmann (2 patches)
- handle errors in batadv_init(), by Minhong He
- correct NET_RX_* NET_XMIT_* confusion, by Sven Eckelmann
- remove negative returns for batadv_send_skb_unicast,
by Sven Eckelmann
* tag 'batadv-next-pullrequest-20260805' of https://git.open-mesh.org/batadv:
batman-adv: remove negative returns for batadv_send_skb_unicast
batman-adv: correct NET_RX_* NET_XMIT_* confusion
batman-adv: handle errors in batadv_init()
batman-adv: switch var declarations to reverse x-mas tree order
batman-adv: split multiple declarations per line
batman-adv: annotate functions which may reallocate the skbuff
batman-adv: fix kernel-doc for functions holding skb ownership
batman-adv: add missing kernel-doc comments
batman-adv: tvlv: handle negative tvlv processing return codes
batman-adv: dat: drop non-4addr backwards compatibility
====================
Link: https://patch.msgid.link/20260805143200.722098-1-sw@simonwunderlich.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
