Repository navigation
Rebase edera/mainline onto master @ 330517c63aa9 - #56
Closed
edera-rebase-app[bot] wants to merge 8317 commits into
Closed
edera-rebase-app[bot] wants to merge 8317 commits into
edera-rebase-app[bot] wants to merge 8317 commits into
Conversation
gtp_genl_new_pdp() calls gtp_find_dev(), which looks the device up with dev_get_by_index_rcu(). Since commit e2d1bac ("gtp: remove useless rcu_read_lock()"), this only runs under the rtnl lock, and kernels with CONFIG_PROVE_RCU_LIST warn: WARNING: suspicious RCU usage net/core/dev.c:1047 RCU-list traversed in non-reader section!! ... dev_get_by_index_rcu gtp_find_dev gtp_genl_new_pdp Hold the RCU read lock around the lookup only: gtp_pdp_add() allocates with GFP_KERNEL, and the rtnl lock keeps the device alive afterwards. Found with the gtp selftest on a debug kernel. Fixes: e2d1bac ("gtp: remove useless rcu_read_lock()") Signed-off-by: Anil Kaushik <anilkaushikwireless@gmail.com> Link: https://patch.msgid.link/20261016093225.1036375-3-anilkaushikwireless@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The GTP (GPRS Tunnelling Protocol, user plane) generic netlink family has no YAML specification under Documentation/netlink/specs/, so it cannot be consumed by the ynl tooling used for user-space clients, documentation and selftests. Add a genetlink-legacy spec describing the existing family: the PDP context management commands (NEWPDP, DELPDP, GETPDP) and the GTP-U echo request (ECHOREQ), the GTPA_* attribute set, and the "gtp" multicast group. Command and attribute values are taken from include/uapi/linux/gtp.h and match it one-to-one. The request attributes of each command are the ones its handler in drivers/net/gtp.c reads, and the reply attributes the ones gtp_genl_fill_info() emits. The notifications sent on the "gtp" group are not described: they reuse the command values of the NEWPDP, DELPDP and ECHOREQ requests, which the ynl code generator cannot express with the existing uapi header. The family doc says so. Add the matching CFLAGS_gtp entry to tools/net/ynl/Makefile.deps, so the generated code is built against the tree's gtp.h instead of an older one installed on the host. This only adds the description; there is no kernel code or uapi change. Signed-off-by: Anil Kaushik <anilkaushikwireless@gmail.com> Link: https://patch.msgid.link/20261016093225.1036375-4-anilkaushikwireless@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Exercise the gtp generic netlink family through its ynl spec: create a gtp device, add a PDP context with newpdp, check getpdp dumps it on that device with the expected TEIDs and addresses, and that delpdp by TEI removes it. Two more cases check that two contexts are dumped and one can be deleted by its MS address, and that deleting an unknown context fails with ENOENT, both by TEI and by MS address. ynl resolves the family ids once per process, with a CTRL_CMD_GETFAMILY dump which does not autoload modules, so the gtp device is created before the family handle: that loads gtp.ko through its rtnl link alias. The test is skipped when the kernel or iproute2 lack GTP support; any other failure to create the device fails it. Add a GtpFamily ynl wrapper and register the test. Signed-off-by: Anil Kaushik <anilkaushikwireless@gmail.com> Link: https://patch.msgid.link/20261016093225.1036375-5-anilkaushikwireless@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
…-selftest' Anil Kaushik says: ==================== gtp: ynl spec for the GTP netlink family, two fixes, and a selftest This adds a ynl spec for the gtp genetlink family, two small driver fixes, and a selftest. Patch 1: the GET and dump replies carried the family id in the command field, so ynl dropped them. Use GTP_CMD_GETPDP instead. Patch 2: new in v7. On the netdev CI debug kernel, the selftest hit an RCU warning: adding a PDP context looks up the device without the RCU read lock. Hold it around the lookup. Patch 3: the spec (NEWPDP/DELPDP/GETPDP/ECHOREQ), no uapi change. Patch 4: a selftest that adds, dumps and deletes PDP contexts. The multicast notifications are not in the spec: they reuse the request command values, which the ynl C generator can't express with the current uapi header. v6: https://lore.kernel.org/netdev/20261013031000.528393-1-anilkaushikwireless@gmail.com/ v5: https://lore.kernel.org/netdev/20261012024800.400616-1-anilkaushikwireless@gmail.com/ v4: https://lore.kernel.org/netdev/20261010105740.223992-1-anilkaushikwireless@gmail.com/ v3: https://lore.kernel.org/netdev/20261009060615.4177402-1-anilkaushikwireless@gmail.com/ v2: https://lore.kernel.org/netdev/20261008181031.4129029-1-anilkaushikwireless@gmail.com/ ==================== Link: https://patch.msgid.link/20261016093225.1036375-1-anilkaushikwireless@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
SO_ZEROCOPY is handled inline in vsock_connectible_setsockopt(). Move it to a helper with a switch on optname, so other SOL_SOCKET options can be added as new cases. The value parsing goes to its own helper too, so each option can do its own checks before it. No functional change. Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20261016132716.272018-2-devnexen@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
SO_INQ makes recvmsg() return the bytes left in the receive queue in an SCM_INQ cmsg, saving a SIOCINQ call per receive. AF_UNIX stream sockets support it, AF_VSOCK fails with ENOPROTOOPT. Add it for SOCK_STREAM, reusing the hint already computed for io_uring. As with TCP_INQ, 1 is reported once the stream is finished so the caller reads again and sees EOF, and accepted sockets inherit the setting from the listener. No cmsg is sent when the transport cannot report the queue length. SOCK_SEQPACKET is refused, as on AF_UNIX: its transport callback counts messages, not bytes. Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Link: https://patch.msgid.link/20261016132716.272018-3-devnexen@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Check the SCM_INQ value after a partial receive, after draining the queue and at EOF, that no cmsg is sent while the option is off, that accepted sockets inherit it from the listener, and that out of range values and SOCK_SEQPACKET are rejected. Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Bobby Eshleman <bobbyeshleman@meta.com> Signed-off-by: David Carlier <devnexen@gmail.com> Link: https://patch.msgid.link/20261016132716.272018-4-devnexen@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
David Carlier says: ==================== vsock: SO_INQ for stream sockets This is the follow-up announced in the receive queue hint series [1]: SO_INQ and SCM_INQ for AF_VSOCK stream sockets, as AF_UNIX has. Patch 1 moves the SOL_SOCKET option handling to a helper without functional change, patch 2 adds SO_INQ and patch 3 covers it in vsock_test. The value is the one SIOCINQ returns, so on Hyper-V it covers the current packet only. Accepted sockets inherit the flag from the listener, and the sockmap receive path does not report it. Tested over loopback with vsock_test and vsock_uring_test. v2: https://lore.kernel.org/netdev/20261015154334.3217358-1-devnexen@gmail.com/ v1: https://lore.kernel.org/netdev/20261012235524.41468-1-devnexen@gmail.com/ [1] https://lore.kernel.org/netdev/20260923184008.153541-1-devnexen@gmail.com/ ==================== Link: https://patch.msgid.link/20261016132716.272018-1-devnexen@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add missing newlines at the end of debug prints. Signed-off-by: Marek Vasut <marex@nabladev.com> Link: https://patch.msgid.link/20261016183804.39217-1-marex@nabladev.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
virtio-net uses a boolean to gate rx_mode_work during device teardown. The flag is changed under RTNL, but ndo_set_rx_mode checks it under the address-list lock. A callback can therefore pass the check and enqueue work after teardown has flushed it. The work is also enabled before late probe operations that can fail, allowing probe unwind to free the netdev with work still queued. KASAN reports the worker using a virtqueue that probe unwind already freed: BUG: KASAN: slab-use-after-free in virtqueue_add_split Workqueue: events virtnet_rx_mode_work Call Trace: virtqueue_add_split (drivers/virtio/virtio_ring.c:706) virtqueue_add_sgs (drivers/virtio/virtio_ring.c:2839) virtnet_send_command_reply (drivers/net/virtio_net.c:3565) virtnet_rx_mode_work (drivers/net/virtio_net.c:3833) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405) Freed by task 119: kfree (mm/slub.c:6625) vp_del_vq.isra.0 (drivers/virtio/virtio_pci_common.c:259) vp_del_vqs (drivers/virtio/virtio_pci_common.c:285) virtnet_probe (drivers/net/virtio_net.c:7129) Use the workqueue disable mechanism to atomically reject new queue attempts and drain running work. Keep work disabled until probe succeeds or restore has reattached the netdev, then enable it and replay receive-mode state for a running interface. Disable it before resource teardown in freeze and remove. Fixes: b9f7425 ("virtio-net: convert rx mode setting to use workqueue") Cc: stable@vger.kernel.org Reported-by: <co+d17c2bc750a9cbbb@bugs.sh> Assisted-by: LLM Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20261017114237.2786302-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
mlx5hws_pat_compare_pattern() casts each __be64 action to __be32 to compare only its control dword. On big-endian this keeps the data dword instead, which HWS clears from the pattern of set and add actions. Two such actions writing the same value into different fields then share a pattern and the second rule modifies the wrong field. Read the first dword of each action from memory instead. Little-endian behavior is unchanged. Discovered by an AI code review agent [1] and confirmed by code inspection. Not reproduced for lack of big-endian hardware running HWS. Tested for regressions on ConnectX-7 with firmware 28.48.1000 on a little-endian host. Fixes: aefc15a ("net/mlx5: HWS, added modify header pattern and args handling") Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261010120147.135825-1-acassen%40corp.free.fr [1] Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Alexandre Cassen <acassen@corp.free.fr> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Link: https://patch.msgid.link/20261019133159.1742411-2-acassen@corp.free.fr Signed-off-by: Paolo Abeni <pabeni@redhat.com>
mlx5_fs_hws_mh_pool_match() compares a single dword of each action since rules pass their values as arguments. Copy and add_field actions keep their destination in the second dword and HWS reads them from the pattern alone. Two modify headers whose copies differ only in destination then share a pool and the second rule writes to the wrong field. Use the HWS core comparison that checks these actions in full. Found while checking a Sashiko AI review report and confirmed against the HWS pattern code. Not reproduced. No in-kernel user puts such actions on the FDB but RDMA flow actions can. Tested for regressions on ConnectX-7 with firmware 28.48.1000 on a little-endian host. Fixes: b36315c ("net/mlx5: fs, add HWS modify header API function") Signed-off-by: Alexandre Cassen <acassen@corp.free.fr> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Link: https://patch.msgid.link/20261019133159.1742411-3-acassen@corp.free.fr Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Alexandre Cassen says: ==================== net/mlx5: HWS, fix modify header pattern compare The fs_hws modify header pools and the HWS pattern cache decide whether two modify headers can share a pattern. Two bugs let different patterns compare equal: - On big-endian the HWS core comparison checks the data dword of each action instead of its control dword. - The fs_hws pool match ignores the destination of copy and add_field actions. Patch 2 moves the pool match to the HWS core comparison that patch 1 fixes. v2: https://lore.kernel.org/netdev/20261012101937.1335231-1-acassen@corp.free.fr/ v1: https://lore.kernel.org/netdev/20261010120147.135825-1-acassen@corp.free.fr/ ==================== Link: https://patch.msgid.link/20261019133159.1742411-1-acassen@corp.free.fr Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The native ACL key set cannot express IP TTL or ICMP type/code. Use the User Defined Filter windows to match them in the tc flower offload. Signed-off-by: David Yang <mmyangfl@gmail.com> Link: https://patch.msgid.link/20261017023136.2961543-1-mmyangfl@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
For the verifier unwind_exit of an exception callback is exit. For JITs the callback is a subprog, so they emit the lookup of the return address. The idea was that the kernel calls the callback and the lookup finds nothing. But an exception callback has no frame of its own. It returns from the frame of the main prog that threw, and the kernel isn't always the caller of that one: - An extension returns to the caller of the subprog that it replaced. - After a tail call in a subprog the main prog returns to the caller of that subprog. When unwind_goto follows that call, the callback goes to the pad, and the pad wasn't verified with it: r6 = 1 call a // can unwind unwind_goto pad r6 = 2 call b // cannot unwind unwind_goto pad // stays, since the pad is not dead code exit pad: r0 = r6 // r6 is 1 for the verifier An extension without unwind_exit can replace b(). When it throws and its exception callback ends with unwind_exit, the pad runs with r6 = 2. Both JITs ask bpf_prog_can_unwind(). Let it say no for an exception callback. An async callback has a frame of its own and the kernel is the caller. Fixes: a2d2747 ("bpf: Add unwind_goto and unwind_exit insns") Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/5f24cbed1ec4a6a0ecd0b834d738c48dc9eb64362be4fa50dfb0eaddfad928b3@mail.kernel.org/ Link: https://patch.msgid.link/20261020231942.2568163-2-alexei.starovoitov@gmail.com Closes: https://lore.kernel.org/bpf/sashiko-outbox-179498@kernel.org/
Representation
--------------
Represent ALU32 recurrences as:
w0 += step -> (zext32 (linear r0 step))
Extend simplify() rules to maintain the above form for latch
expressions. E.g. for a post-condition loop such as:
w0 = 0;
l: w0 += 1;
if w0 != 3 goto l;
exit;
SCEV at header: (zext32 (linear r0 1))
Initial SCEV at latch: (zext32 (+ (zext32 (linear r0 1)) 1))
Simplified SCEV at latch: (zext32 (+ (zext32 (linear r0 1)) 1))
-> (zext32 (+ (linear r0 1) 1))
-> (zext32 (linear (+ r0 1) 1))
Iterations count computation
----------------------------
- Extract the main iteration-count logic from compute_max_iters() into
compute_backedge_taken_count(). Reuse its 64-bit arithmetic after
sign/zero extending the latch operands.
- Reject the computed count if the predicted exit value falls outside
signed/unsigned 32-bit range, e.g.:
w0 = 0x7ffffffe;
l: w0 += 1;
if w0 s<= 0x7fffffff goto l;
The 64-bit computation predicts an exit at S32_MAX + 1, but the
32-bit value wraps to S32_MIN and the comparison remains true.
- Handle mixed 64-bit/32-bit comparisons/recurrences only when initial
bounds and step fit in 32-bit ranges, e.g.:
w0 = 0;
r1 = 0x100000003 ll;
l: w0 += 1;
if r0 != r1 goto l;
Truncating the bound to 32 bits would predict three header visits.
However, `w0 += 1` keeps r0 within [0, U32_MAX], so it can never
be equal to the 64-bit bound.
Widened bounds computation
--------------------------
- Update linear_bounds() to truncate the initially computed 64-bit
range to 32 bits, then zero-extend it to obtain the 64-bit range
of iteration values. Step computation needs to handle:
- unsigned 32-bit wraparound;
- entry and zero-extended iteration values disagreeing on base/step.
- Union both ranges with the corresponding register ranges at entry,
since the entry value need not be zero-extended.
- Extend `struct bounds` to keep both {32,64}-bit ranges and pass both
to bpf_set_reg_range(). A 64-bit range alone loses useful 32-bit
information, e.g.:
entry = 0, step = -1, two header visits
r64: [0, U32_MAX]
r32: [-1, 0]
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020-scev-32bit-v1-1-838f34f9f0cd@gmail.com
A prog with unwind_goto or unwind_exit has to be JITed by a JIT that supports them. The driver JITs an offloaded prog, and nobody looks at jit_required there. nfp rejects unwind_goto in nfp_verify_insn(). netdevsim takes everything. Nothing runs such a prog, but it's not jited for bpf_insn_prepare_dump(), which takes unwind_goto for BPF_CALL_ARGS and shows it as a call. Fixes: a2d2747 ("bpf: Add unwind_goto and unwind_exit insns") Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261020231942.2568163-3-alexei.starovoitov@gmail.com Closes: https://lore.kernel.org/bpf/sashiko-outbox-179499@kernel.org/
The post32_* tests exercise scev.c:compute_max_iters():
- 32-bit to 64-bit operand extension and overflow handling.
- <, <=, >, >=, s<, s<=, s>, s>=, != operations.
- Checks exact boundary hits and overflow at S32_MIN, S32_MAX, and
U32_MAX.
The post_cond_jne32* tests exercise zero-extension logic in
scev.c:linear_bounds():
- 32-bit unsigned wraparound.
- Entry and zero-extended iteration values disagreeing on base/step,
requiring the step to be reduced.
- Widened bounds containing both the original entry value and the
zero-extended iteration values.
- Preserving step and base when that union crosses the signed 64-bit
boundary.
The post_cond_alu{32,64}_jmp{64,32} tests cover mixed-width recurrences
and comparisons:
- Declining to compute an iteration count when operands or the
predicted exit fall outside the required 32-bit ranges.
- Computing iteration counts and widened bounds for compatible
mixed-width loops.
Also add a basic pre-condition loop test.
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261020-scev-32bit-v1-2-838f34f9f0cd@gmail.com
In both tests the prog that throws returns to a call that unwind_goto follows, and its exception callback ends with unwind_exit: - An extension replaces a subprog that cannot unwind. unwind_goto after the call stays, since it shares the pad with a call of a subprog that can unwind. - A subprog that can unwind does a tail call. unwind_exit of the callback has to be exit. Without the fix the callers go to the pad and return 2 instead of 3 and 42 instead of 7. Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20261020231942.2568163-4-alexei.starovoitov@gmail.com
Eduard Zingerman says:
====================
bpf: support 32-bit linear scalar evolution
Support scalar evolution widening for loops like:
w0 = 0;
l: w0 += 1;
if w0 != 3 goto l;
exit;
Implementation details are covered in the first patch.
Veristat results follow. Program sets: cilium, meta, scx, selftests.
Tables: success in both runs; baseline Insns >= 5,000.
Ranked by percentage change, then instruction-count change, file,
program. Meta names are anonymized.
Top 50 wins are shown, there are no loses.
Histogram
---------
Total progs: 7994
Old success: 5665
New success: 5665
-100 .. -95 %: 21
-95 .. -85 %: 1
-85 .. -75 %: 4
-75 .. -70 %: 17
-70 .. -65 %: 10
-65 .. -55 %: 3
-50 .. -40 %: 2
-40 .. -30 %: 2
-25 .. -15 %: 2
-15 .. -10 %: 7
-10 .. -5 %: 32
-5 .. 0 %: 6
0 .. 5 %: 7887
Top wins (50)
-------------
File Program Insns (A) Insns (B) Insns (DIFF)
----------------------------- --------------------------------- --------- --------- -----------------
timer_start_delete_race.bpf.o start_timer 40007 28 -39979 (-99.93%)
timer_start_delete_race.bpf.o delete_elem 14003 11 -13992 (-99.92%)
verifier_bounds.bpf.o crossing_32_bit_signed_boundary_2 12330 20 -12310 (-99.84%)
access_map_in_map.bpf.o access_map_in_array 18457 35 -18422 (-99.81%)
access_map_in_map.bpf.o access_map_in_htab 18457 35 -18422 (-99.81%)
access_map_in_map.bpf.o sleepable_access_map_in_array 18457 35 -18422 (-99.81%)
access_map_in_map.bpf.o sleepable_access_map_in_htab 18457 35 -18422 (-99.81%)
firewall-09.bpf.o twfw_connect6 153638 320 -153318 (-99.79%)
firewall-09.bpf.o twfw_sendmsg6 153638 320 -153318 (-99.79%)
firewall-10.bpf.o twfw_connect4 102193 241 -101952 (-99.76%)
firewall-10.bpf.o twfw_sendmsg4 102193 241 -101952 (-99.76%)
firewall-10.bpf.o twfw_connect6 166183 397 -165786 (-99.76%)
firewall-10.bpf.o twfw_sendmsg6 166183 397 -165786 (-99.76%)
firewall-09.bpf.o twfw_connect4 76030 197 -75833 (-99.74%)
firewall-09.bpf.o twfw_sendmsg4 76030 197 -75833 (-99.74%)
linked_list.bpf.o clear_global_array_list 13071 57 -13014 (-99.56%)
rhash.bpf.o test_rhash_update_elements 7584 91 -7493 (-98.80%)
profiler-06.bpf.o on_perf_event 425953 94751 -331202 (-77.76%)
profiler-26.bpf.o handle_cu_mem_address_reserve 45724 12702 -33022 (-72.22%)
profiler-26.bpf.o handle_cu_mem_create 45724 12702 -33022 (-72.22%)
profiler-26.bpf.o handle_malloc 45724 12702 -33022 (-72.22%)
profiler-19.bpf.o sched_switch_offcpu 78210 21906 -56304 (-71.99%)
profiler-26.bpf.o handle_cu_mem_map 45922 12900 -33022 (-71.91%)
profiler-09.bpf.o on_custom_event_start 45973 12951 -33022 (-71.83%)
profiler-09.bpf.o trace_func_entry 45973 12951 -33022 (-71.83%)
profiler-19.bpf.o sched_waking 23153 6642 -16511 (-71.31%)
profiler-27.bpf.o handle_cuda_launch_exc 23176 6665 -16511 (-71.24%)
profiler-27.bpf.o handle_cuda_launch 23189 6678 -16511 (-71.20%)
profiler-12.bpf.o on_custom_event_begin 23396 6885 -16511 (-70.57%)
profiler-12.bpf.o on_custom_event_end 23400 6889 -16511 (-70.56%)
profiler-26.bpf.o handle_mtia_cached_alloc 46892 13870 -33022 (-70.42%)
profiler-26.bpf.o handle_mtia_allocate_enter 46953 13931 -33022 (-70.33%)
profiler-12.bpf.o sched_switch 40257 12105 -28152 (-69.93%)
profiler-26.bpf.o handle_pytorch_malloc 47245 14223 -33022 (-69.90%)
profiler-19.bpf.o oncpu 23689 7178 -16511 (-69.70%)
profiler-12.bpf.o on_task_enqueued 23734 7223 -16511 (-69.57%)
profiler-12.bpf.o sched_waking 23769 7258 -16511 (-69.46%)
profiler-12.bpf.o on_task_dequeued 23909 7398 -16511 (-69.06%)
profiler-12.bpf.o on_request_context_event 24000 7489 -16511 (-68.80%)
profiler-12.bpf.o on_pytorch_event 24001 7490 -16511 (-68.79%)
profiler-12.bpf.o on_task_stats 24083 7572 -16511 (-68.56%)
profiler-12.bpf.o oncpu 24187 7676 -16511 (-68.26%)
scx_rusty.bpf.o rusty_init 8784 3171 -5613 (-63.90%)
profiler-12.bpf.o get_crochet_walltime_stacks 50215 22063 -28152 (-56.06%)
security-sandbox-13.bpf.o kvm_die 5807 2967 -2840 (-48.91%)
profiler-24.bpf.o get_task_stacks 103742 64928 -38814 (-37.41%)
scheduler-01.bpf.o arena_alloc_mask 29208 25497 -3711 (-12.71%)
scheduler-03.bpf.o arena_alloc_mask 29208 25497 -3711 (-12.71%)
file-system-monitor-01.bpf.o file_lineage_lsm_file_free 20986 18354 -2632 (-12.54%)
file-system-monitor-01.bpf.o file_lineage_security_file_free 20986 18354 -2632 (-12.54%)
---
====================
Link: https://patch.msgid.link/20261020-scev-32bit-v1-0-838f34f9f0cd@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Alexei Starovoitov says: ==================== bpf: Fixes for unwind_goto and unwind_exit From: Alexei Starovoitov <ast@kernel.org> Two fixes for what the bots found in v4 [1] of the series that added unwind_goto and unwind_exit. Patch 1. unwind_exit of an exception callback is exit for the verifier, but JITs looked up the return address. The callback returns from the frame of the main prog. After freplace or a tail call that's a return to a prog, and the callback could end up in a pad that wasn't verified with it. It came with 'unwind_exit of an async or an exception callback is exit' in v4. For an async callback that's fine: it has a frame of its own. Patch 2. Offloaded progs with the new insns are rejected. Patch 3. Tests for patch 1. They fail without it. [1] https://lore.kernel.org/bpf/20261020181320.1284798-1-alexei.starovoitov@gmail.com/ ==================== Link: https://patch.msgid.link/20261020231942.2568163-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
tc_edt sends 1MB over a TCP connection that a BPF program shapes with
EDT, and checks that the rate it measures is within 2% of the target
rate. The transfer takes about 200ms, so the margin is about 4ms.
The measurement starts before send_recv_data(), which first creates the
sender thread and accepts the connection. On a KASAN kernel, x86_64 VM
with 32 vCPUs, that takes 0.7ms when idle and up to 4.7ms with all
CPUs busy, while the BPF program spreads the data over 200.08ms in the
median. The test also fails without test_progs -j where everything runs
slower, e.g. on s390x and with ASAN in BPF CI.
Have the BPF program note when the first packet with data goes out, and
start the measurement there.
tc_edt run 100 times on the same VM, idle and with 32 busy loops in the
background, before and after this patch:
before after
idle 0 of 100 failed 0 of 100 failed
busy loops 3 of 100 failed 0 of 100 failed
Fixes: b0f82e7 ("selftests/bpf: integrate test_tc_edt into test_progs")
Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Link: https://patch.msgid.link/20261019-selftests-bpf-tc-edt-serial-v2-1-41c3813e7916@gmail.com
Add a driver for the GPIO controller embedded in the Toshiba TC9563 PCIe switch (and the Qualcomm QPS615). The device implements 37 GPIOs using two register banks: three registers control the first 32 GPIOs and three more control GPIOs 32-36. GPIOs 20 and 21 are reserved while GPIOs 22-24, 27-28, 31, and 34 are input-only. Register the driver as an auxiliary device driver. The TC9563 power controller creates the auxiliary device and provides a regmap that gives access to the GPIO registers, so use the gpio-regmap helpers to implement the GPIO chip. Signed-off-by: Alex Elder <elder@riscstar.com> Co-developed-by: Daniel Thompson <daniel@riscstar.com> Signed-off-by: Daniel Thompson <daniel@riscstar.com> Co-developed-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> [bhelgaas: commit log per https://lore.kernel.org/arQ2mDjqHv4gmoOK@lore-desk] [bhelgaas: squash Geert Uytterhoeven <geert+renesas@glider.be> Kconfig fix: https://lore.kernel.org/all/45484c37512a3102495d8b75b6e9f72a141ba42e.1792574560.git.geert+renesas@glider.be, Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-2-c9b33f56c8d3@oss.qualcomm.com
The TC9563 PCIe switch embeds a GPIO controller providing 37 GPIO lines, accessed through the switch's I2C interface. The controller is integrated in the switch rather than being a separate device, so expose it by adding the gpio-controller and #gpio-cells properties to the switch node itself, and extend the example to show the downstream ports' reset-gpios being driven from those lines. Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-1-c9b33f56c8d3@oss.qualcomm.com
The TC9563 embeds a GPIO controller used for per-port reset signals. Create an auxiliary device for it so the gpio-tc9563 driver can register the GPIO chip and enable DT-based GPIO lookups. Pass the tc9563 regmap to the auxiliary device as its platform data. The pwrctrl driver does not wait for the GPIO chip to be probed. The per-port reset GPIO lookup, returning -EPROBE_DEFER until the chip is registered, is added in the next patch. Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> [bhelgaas: squash Geert Uytterhoeven <geert+renesas@glider.be> Kconfig fix: https://lore.kernel.org/all/45484c37512a3102495d8b75b6e9f72a141ba42e.1792574560.git.geert+renesas@glider.be, Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-3-c9b33f56c8d3@oss.qualcomm.com
Remove the local TC9563_GPIO_MASK and TC9563_GPIO_DEASSERT_BITS definitions, which are no longer used after switching to the GPIO descriptor API. Move TC9563_GPIO_CONFIG and TC9563_RESET_GPIO definitions in tc9563.h header file. Replace the direct regmap-based per-port reset logic in assert_deassert_reset() with gpiod_direction_output() calls, falling back to the legacy regmap approach only when no reset-gpios DT property is present for a given port. Add the reset GPIO pointer to struct tc9563_pwrctrl_cfg and introduce tc9563_pwrctrl_parse_reset_line() to look up reset-gpios from each PCI downstream port child node. The lookup is done lazily at the beginning of power_on(), returning -EPROBE_DEFER until the GPIO chip is registered. Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://patch.msgid.link/20260909-pci-tc9563-aux-v5-4-c9b33f56c8d3@oss.qualcomm.com
of_regulator_bulk_get_all() allocates the consumers array and returns it to the caller, who is expected to free it at an appropriate time. PCI pwrctrl never did, leading to a memory leak. Add an explicit kfree() for the consumers array. Fixes: 75996c9 ("PCI/pwrctrl: Add pwrctrl driver for PCI slots") Signed-off-by: Alexey Charkov <alchark@flipper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260930-pci-pwrctrl-kfree-v1-1-f09bbffd8da3@flipper.net
pci_pwrctrl_create_device() only creates platform devices for OF nodes that pci_pwrctrl_is_required() accepts, but pci_pwrctrl_destroy_device() unregisters the platform device of every available child node without that check. Nodes under a PCI host controller that are not pwrctrl devices may have been populated by another mechanism. Destroying them here would tear down devices owned by other code. Mirror the check done at creation time so that only devices created by the pwrctrl core are removed. Fixes: 4c41324 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices") Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/1791446700-100166-1-git-send-email-shawn.lin@rock-chips.com
pci_pwrctrl_power_on_device() recursively powers on the child nodes of a device before powering on the device itself. If powering on a child fails (e.g. returning -EPROBE_DEFER), the function returned immediately, leaving the sibling children that were already powered on in the same loop iteration enabled. Since probe deferral is a standard boot path, this leads to unbounded regulator and clock enable increments across retries. The error path in pci_pwrctrl_power_on_devices() only powers off the top-level children processed before the failing one and explicitly stops at it, so it can never clean up the siblings leaked deeper in the failed subtree. Power off the sibling children that were successfully powered on before a child fails, and power off all children if the device's own power_on() fails after its children were already enabled. Switch to a manual child iterator so the failing node can be tracked and its reference released in the error path. Fixes: b35cf3b ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices") Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://patch.msgid.link/20260909-pwrtctl-power-on-rallback-v1-1-412ef996ba27@oss.qualcomm.com
- Fix aer_recover_queue() leak when ACPI APEI/GHES error events overflow the kfifo (Priyank Rathod) - Fix aer_recover_work_func() leak when ACPI APEI/GHES events mention a pci_dev that no longer exists (Priyank Rathod) - Document that aer_recover_queue() takes ownership of aer_regs structures passed to it by ACPI APEI/GHES (Priyank Rathod) - Fix aer_process_err_devices() leak when a device is recorded as an error source purely by being mentioned in the Root Port Error Source and the device is inaccessible or logged only masked errors (Priyank Rathod) * pci/aer: PCI/AER: Fix struct pci_dev reference leak in aer_process_err_devices() PCI/AER: Document that aer_recover_queue() takes ownership of aer_regs PCI/AER: Fix memory leak in aer_recover_work_func() when pci_dev is missing PCI/AER: Fix memory leak in aer_recover_queue() on kfifo buffer overflow
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means rewriting its direct map PTE through Xen. The
per-page helpers in drivers/xen/mem-reservation.c make one
HYPERVISOR_update_va_mapping call per page.
Add exported helpers that do the same for a contiguous run in batches,
through HYPERVISOR_mmu_update as xen_remap_pfn() does:
- xen_zap_contig_pfns() unmaps a run and invalidates its p2m entries,
for pages about to be handed to Xen.
- xen_remap_contig_pfns() maps a run onto frames Xen has just
populated. It writes the p2m with __set_phys_to_machine(), which
never allocates, so the caller runs xen_prealloc_p2m_range() over
the run first, before the populate hypercall, while a failure can
still be backed out of.
Both return the first failure, whether a PTE they could not find or Xen
refused to update, or a p2m entry that could not be written, and leave
what to do about it to the caller. mmu_update reports a failure back to its caller, where a
multicall batch would only log it.
Neither flushes the TLB: the intended caller only maps over PTEs that
were already cleared, and flushes after unmapping itself.
PVH domains never reach these: their page tables hold guest frames,
which do not change when Xen moves the machine frames behind them.
No callers yet.
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means updating its direct map PTE and p2m entry. The
existing helpers for that take parallel arrays of pages and frames, one
entry per page. That fits order-0 extents, where Xen reports a frame per
page, but not an ordered extent, where it reports only the base frame.
Add variants that take a base page, and for mapping a base frame, and
derive the rest of a contiguous run from them, on top of the batched arch
helpers:
- xenmem_reservation_va_mapping_reset_contig() unmaps a run before its
frames are handed to Xen.
- xenmem_reservation_p2m_prealloc() and
xenmem_reservation_va_mapping_update_contig() map a run in once Xen
has populated it. The mapping step cannot allocate, so the
preallocation is a separate call, made before asking Xen to
populate: it is the only step expected to fail, and failing after
the populate would strand the frames Xen handed over.
The two directions treat a failed update differently:
- A failed map is fatal, as in the per-page helper. Callers treat the
run as mapped once the call returns, and a page with no mapping
would fault wherever it was next used, far from the cause.
- A failed unmap only warns, unlike the per-page helper. The frame
stays mapped, and Xen will not hand it to another domain while it
is, so the frame leaks but nothing is corrupted.
All three are no-ops outside a PV domain, like the helpers they sit
beside.
No functional change: the new helpers have no callers yet.
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
The balloon inflates a page at a time: it takes whatever pages the guest
buddy allocator hands out and returns their frames to Xen one order-0
extent each. Those frames need not form an aligned run, so Xen's
free_heap_pages() cannot merge them back into a 2 MiB buddy.
Add a second unit of trade, a block of 1 << 9 Xen pages: 2 MiB, the
largest extent Xen grants a domain asking on its own behalf. Inflate now
takes a whole free block with one alloc_pages() and parks it on a block
list, so its frames go back to Xen as an aligned run. On PV the block is
unmapped with the batched contiguous-run helper; on PVH there is nothing
to unmap.
The extents submitted stay order-0. XENMEM_decrease_reservation
releases each frame individually whatever the extent order, so an
ordered extent would change nothing there while asking Xen to trust that
the block is machine-contiguous, a claim it cannot check for a PV
domain, where the frame number it is handed is already the machine
frame.
A block is only an option, never a requirement, in either direction:
- balloon_inflate() takes a block only when the guest has a whole free
2 MiB run, without reclaiming or compacting to make one, and
otherwise inflates a page at a time. A guest with plenty of free
memory can still have no such run, and that must not stop it
shrinking.
- Deflate still populates a page at a time and walks only the page
list, which cannot see blocks. When that list is empty it now breaks
a parked block onto it, so the guest can always grow back into
memory it gave up as a block.
The OOM notifier sized its deflate from the page list counters alone,
so a balloon holding only blocks would look empty to it and the OOM
killer would run while the balloon still held memory. It now counts
block pages too, and its deflate reaches them through the block-breaking
path above.
Set xen.balloon_superpages=0 to inflate a page at a time as before.
Backends: PV, PVH
Direction: inflate (frames move from the guest to Xen); deflate only
changes to consume blocks
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
Deflate still breaks a parked block into pages and asks Xen to populate
each with its own order-0 extent, which lets Xen back the block with any
512 frames it has.
Populate a parked block as a single order-9 extent instead, so that Xen
allocates one machine-contiguous 2 MiB run for it:
- On PVH Xen maps that run with a single 2 MiB EPT entry rather than
512 4 KiB ones.
- On PV there is no EPT, and the guest cannot use 2 MiB mappings. The
guest maps the run in itself, with the batched contiguous-run
helper, from the base machine frame Xen reports.
The p2m leaves of each block are preallocated while walking the block
list, before the populate hypercall: mapping the block afterwards cannot
allocate, and once Xen has populated an extent there is no way to hand
it back. Failing there only shortens the batch.
A block is only an option here too. balloon_deflate() falls back to the
page at a time path when a block makes no progress: Xen refuses an
order-9 extent when the host has no free 2 MiB run, or when the domain
is less than 2 MiB below its max_pages ceiling, and neither should stop
the guest growing by what it can still get. Credits smaller than a block
take the page at a time path as well.
Blocks are populated at most BALLOON_BLOCK_BATCH at a time, which bounds
the work done under balloon_mutex; the OOM notifier can only trylock it.
Backends: PV, PVH
Direction: deflate (frames move from Xen to the guest)
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
The OOM notifier deflates through increase_reservation(), which works a page at a time and reaches parked blocks only by breaking them up. Deflate through balloon_deflate() instead, so that an OOM deflate populates a whole block as a single order-9 extent where Xen can supply one, and still falls back to single pages where it cannot, including the last 2 MiB below the domain's max_pages ceiling. Backends: PV, PVH Direction: deflate (frames move from Xen to the guest) Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
xen_init_time_common() points x86_platform.calibrate_tsc at xen_tsc_khz() but leaves calibrate_cpu native, so tsc_early_init() -> determine_cpu_tsc_frequencies() still calls native_calibrate_cpu_early() for cpu_khz. That tries CPUID 0x16, then MSR_PLATFORM_INFO, and then falls through to quick_pit_calibrate() -- which on a PVH guest waits out its full 50ms timeout on a PIT that is not there, prints "Fast TSC calibration failed", and arrives at a value the hypervisor had already been asked for a moment later. It is 48ms of every boot, and it is the largest single item in one: a 512 MiB PVH guest reached "Run /init as init process" at 0.330s, and 0.118s once this and the xenbus boot wait were out of the way. There is nothing for the calibration to find out here. Xen reports the TSC frequency, tsc_khz already comes from it, and cpu_khz differing from tsc_khz under a hypervisor is not information -- determine_cpu_tsc_frequencies() would overwrite cpu_khz with tsc_khz anyway once they disagree by more than 10%. Note that tsc_early_khz= does not help: it only short-circuits calibrate_tsc, and the 50ms is spent in calibrate_cpu. Set in xen_init_time_common() so PV and PVH/HVM guests both get it, which is where calibrate_tsc is already set for the same reason. Signed-off-by: Alex Zenla <alex@edera.dev>
boot_wait_for_devices() sleeps HZ/10 between checks, so on a CONFIG_HZ=100 kernel it waits a tenth of a second to notice something that has already happened. What it is waiting for is not slow: a toolstack has every backend sitting in XenbusStateInitWait before it unpauses the guest, so the wait covers the frontend half of the handshake, which finishes a few milliseconds after the late_initcall starts looking. Measured on a PVH guest, the last frontend connected at 0.232s and init started at 0.311s -- 79ms of sleeping past the event. Frontends move to XenbusStateConnected (and blkfront sets is_ready) from their otherend_changed callback, which runs from the frontend bus's backend_changed() watch. Bump a sequence count and wake a wait queue there, and have wait_for_devices() sleep on it instead of for a fixed interval. The sequence is sampled before each check, so a change that lands between the check and the sleep still wakes the waiter. The HZ/10 interruptible sleep stays as the timeout, so state changes that do not come through the watch are noticed no later than before, and the 30/270-second budgets and their reporting are unchanged. Signed-off-by: Alex Zenla <alex@edera.dev>
Port the nightly upstream rebase from the Xen tree to the kernel. Every night at 03:23 UTC, Claude rebases edera/mainline onto torvalds master, following .automation/skills/upstream-rebase/SKILL.md: it replays the series, resolves conflicts, fixes what the replay broke, builds, audits upstream fixes that meet the series, and writes a report. The model's own account of its result decides nothing. It runs with a read-only token; its branch leaves the job as a git bundle and is judged by scripts taken from the commit the run started from: - verify-upstream-rebase.sh (unchanged from Xen) proves the series sits on the upstream tip, is linear, kept every commit, and moved the tree by exactly the upstream delta; - kernel-build.sh builds x86_64 and arm64 vmlinux with the Hyper-V, Xen dom0/backend, PV-IOMMU, NUMA affinity and OpenPaX options built in, and fails if olddefconfig drops any of them. If both pass and the report asks for no decision, edera/mainline is force-pushed with a lease pinned to the tip the rebase started from, and the old tip is kept as a backup branch. Otherwise the result goes up as a pull request carrying the report, and approving it lands it (rebase-land.yml). A night with no result opens an issue. Every job clones blobless: the jobs need the kernel's commit graph but only the contents of the files the series and upstream touch.
The rebase runs from a scheduled or dispatched event and needs its own federation rule rather than the organization-wide one, so read it from vars.REBASE_FEDERATION_RULE_ID.
edera/6.18-lts carries its own rebase automation, but scheduled workflows run only from the default branch. Add a workflow here whose only job is to dispatch edera/6.18-lts's kernel-nightly.yml each night.
OPENPAX currently defaults to y, which means OpenPaX gets enabled for any configuration that picks up the new symbol, including ones that never asked for it. Default it to n so it has to be selected explicitly. While at it, make OPENPAX_SOFTMODE depend on OPENPAX. Soft mode does nothing without OpenPaX enabled, so there is no reason for it to be selectable (and default y) on its own. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit 514cd60)
edera/6.18-lts proposes a backport of each pull request merged into edera/mainline, driven by its own workflows. Add a workflow here whose only job is to dispatch that, skipping pull requests labelled no-backport and the nightly's rebase pull requests.
xen-pciback seizes a hidden device in an fs_initcall, but the Xen IOMMU registered from a device_initcall. Registering probes every PCI device that already exists, so a hidden device was found with a driver bound and the IOMMU core warned about a late probe at driver bind. Register from subsys_initcall_sync instead, so the IOMMU is in place before pciback binds anything. Signed-off-by: Alex Zenla <alex@edera.dev>
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
All of the extra memory Linux reserves at boot goes to the mapping pool, so dom0's balloon starts empty. Growing dom0 at runtime then means memory hotplug, which places the new range at the first free physical address: on PVH that is the host's own map, where nothing guarantees the range is not a device's MMIO window. Keep the part of the extra memory dom0 may grow into on the balloon instead. Xen's ceiling for dom0 (dom0_mem=...,max:) sizes that part, so a host booted without a max: keeps today's behaviour. Every region gives up the same fraction, which spreads the growth over the NUMA nodes on PVH and leaves each node's mapping pool its share, and the last memory section stays with the pool so that early grant mappings never fall back to holes in the physical map. Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
A request that does not fit in its ring sleeps in io_wait_event_killable() until the backend frees space, but the event handler wakes the ring with wake_up_interruptible(), which only wakes TASK_INTERRUPTIBLE sleepers. A TASK_KILLABLE waiter therefore sleeps until it is killed, which hangs a guest that has enough large requests in flight to fill a ring. Wake the ring with wake_up() so killable waiters see the freed space. Fixes: 9523fea ("net/9p: Switch to wait_event_killable()") Signed-off-by: Alex Zenla <alex@edera.dev>
The frontend's resume handler only warned that suspend and resume are unsupported. After a restore its rings, grant references and event channels are gone, yet the mounted client kept writing requests into them, so every request on the mount hung. The next InitWait from the backend then allocated a second frontend instance for the same device, which no client used. On resume, collect any replies the backend left in the rings, free the rings, fail the requests that are still unanswered with -EIO, and publish Initialising so that a backend which still serves the old rings starts over. When the backend reaches InitWait, allocate and publish new rings for the existing frontend, keeping its clients. Requests that arrive while the frontend is not connected wait until it is, and a rw_semaphore keeps them off the rings while a resume replaces them. Signed-off-by: Alex Zenla <alex@edera.dev>
A forked, restored or imported domain resumes against a new backend whose fid table is empty, while the guest's 9P clients still hold the fids of the session they were suspended with. With the transport reconnected every request on those fids still fails, so even an idle mount comes back unusable. When the backend advertises feature-session-transfer, wait at suspend for the requests in flight to be answered, then ask the backend for its fid table with Tsession_save and keep the pages in guest memory, where they survive into whatever domain the guest resumes in. Once a restored frontend's new backend connects, replay the pages with Tsession_restore before any request can use the rings. The pages are opaque to the frontend; the backend validates every entry as it would a walk or open. Signed-off-by: Alex Zenla <alex@edera.dev>
The toolstack has to know whether a guest can carry its 9P session into a new backend before it exports the domain, because a guest that cannot comes back with every open file on its mounts unusable. Until now only the backend advertised the feature, and the frontend's support was invisible from dom0. Publish feature-session-transfer = 1 in the frontend's own xenstore directory, next to version and num-rings. Signed-off-by: Alex Zenla <alex@edera.dev>
arch/x86/xen/enlighten.c includes xen/interface/memory.h for XENMEM_maximum_reservation, but memory.h uses xen_ulong_t, domid_t and GUEST_HANDLE without including where they are defined, xen/interface/xen.h. Other configurations reach those through an earlier include. The zone-tiny configuration does not, and fails to build with CONFIG_WERROR=y: include/xen/interface/physdev.h:41:5: error: unknown type name 'xen_ulong_t' Include xen/interface/xen.h first, as arch/arm/xen/enlighten.c does. Signed-off-by: Alex Zenla <alex@edera.dev>
A node whose pool is short called fill_list() even when other nodes still held free pages. fill_list() takes new address space from iomem_resource, which on a PVH dom0 can overlap MMIO that Xen has identity mapped. A later grant map onto such a gfn makes Xen refuse the p2m change and crash dom0. Carve a new region only when every node's pool is short, and otherwise take pages from the preferred node first, then the others. Return pages to the pool of their own node when the PV p2m allocation fails.
…ode variant Borrowing across nodes made xen_alloc_unpopulated_pages_node() best effort, so a caller that asked for a node could get pages of another. The node variant now takes pages only from the requested node's pool and fails with -ENOMEM when it is short. It no longer carves a region. xen_alloc_unpopulated_pages() has no node requirement: it prefers the local pool, borrows from other nodes, and carves a region only when every pool is short. xenbus falls back to it when the node's pool is short, and gnttab_alloc_pages_node() uses it for NUMA_NO_NODE.
GitHub starts no workflow for a review of a pull request it cannot compute a merge ref for, and a rebase often conflicts with the tree it replaces: approving #48 started nothing, and it had to be landed by hand. The land workflow can now also be run with a pull request number. It then reads the head, branch and base from the pull request, requires the same rebase/edera-mainline/... branch into edera/mainline, and lands on the most recent approval of the current head from a reviewer whose latest review is still an approval. Everything after that, the write-access check, the tip check, the backup and the leased push, is unchanged.
When a backport pull request merges into edera/6.18-lts, delete its branch and retry the mainline pull requests waiting for it. A backport/edera-6.18-lts/pr-<N> branch is the automation's own and is of no use once its pull request has merged, but delete_branch_on_merge stays off so feature branches survive, and the merged ones pile up. It is deleted only if it still points at the commit that merged. The retry was meant to happen already, from lts-backport-merged.yml on edera/6.18-lts, but that has never run: pull_request_target always takes the workflow from the default branch. This copy of that path lives on edera/mainline and runs edera/6.18-lts's retry-backports.sh.
edera/6.18-lts audits itself for Edera commits from edera/mainline that it lacks (kernel-nightly.yml with audit=true), but scheduled workflows run only from the default branch. Add a workflow here whose only job is to dispatch that audit every Monday.
3 of 4 tasks
commented
Oct 26, 2026
Author
|
Superseded by #57. |
edera-rebase-app
Bot
deleted the
rebase/edera-mainline/20261025-017f96b23bf1-330517c63aa9
branch
October 26, 2026 04:31
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nightly rebase of
edera/mainline(017f96b23bf1) ontomaster(330517c63aa9), driven by Claude. Not pushed automatically because the checker found drift. Run log.Important
Do not use the merge button: this branch replaces
edera/mainlinerather than merging into it. Approve the pull request to land it; the land workflow force-pushesedera/mainlineto the approved head, pinned to017f96b23bf1, and keeps a backup.Independent checks
Builds: success (x86_64 and arm64 vmlinux with the Edera features built in; per-build results in the run).
017f96b23bf1f7909e03c592864c07de0c7d330517c63aa9Commits whose hunk context moved (own +/- lines identical)
ea62ac9f1b0f iommu/xen: Add Xen PV-IOMMU driver→8c91d26ae187bd1c0dba57c3 sysctl: wire up PaX softmode setting→63a60b81fcf0Drift (changed lines: upstream delta vs. actual change)
Claude's report
Claude left no report (rebase step: success).