[ciq-6.18.y-next] Multiple patches tested (100 commits) - #1610
Open
ciq-kernel-automation[bot] wants to merge 131 commits into
Open
ciq-kernel-automation[bot] wants to merge 131 commits into
ciq-kernel-automation[bot] wants to merge 131 commits into
Conversation
Adding configs based of Fedora-ARK default config from 6.18.2.
We are modifying these with the following configs where available CONFIG_MODIFY_LDT_SYSCALL=n CONFIG_LEGACY_VSYSCALL_NONE=n These options are for old software support which adds performance overhead and potential attack surfaces with go against the CIQ LT kernels priority of performance and security. CONFIG_LIVEPATCH=n We do not have Live patching on for any road-map CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y This should be enabled, it often improves performance funnily enough CONFIG_PREEMPT_VOLUNTARY=y CONFIG_HZ=100 These are set to increase throughput CONFIG_PREEMPT_VOLUNTARY=y (default Fedora config) but CONFIG_HZ=100 for higher throughput over the x86_64 default of CONFIG_HZ=1000 which provides lower latency. After modification 'make CROSS_COMPILE=./scripts/dummy-tools/' was run
Setting up the default build configs to ensure everything builds when we update and rebase.
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. Add a kernel configuration option to lock down the kernel, to restrict userspace's ability to modify the running kernel when UEFI Secure Boot is enabled. Based on the x86 patch by Matthew Garrett. Determine the state of Secure Boot in the EFI stub and pass this to the kernel using the FDT. Signed-off-by: Linn Crosetto <linn@hpe.com> [bwh: Forward-ported to 4.10: adjust context] [Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream] [bwh: Forward-ported to 4.15 and lockdown patch set: - Pass result of efi_get_secureboot() in stub through to efi_set_secure_boot() in main kernel - Use lockdown API and naming] [bwh: Forward-ported to 4.19.3: adjust context in update_fdt()] [dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection] [bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this] [bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a sys_table parameter] [bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so: - Add Secure Boot mode to the parameter enumeration in fdtparams.c - Add a parameter to efi_get_fdt_params() to return the Secure Boot mode - Since Xen does not have a property name defined for Secure Boot mode, change efi_get_fdt_prop() to handle a missing property name by clearing the output variable] [Salvatore Bonaccorso: Forward-ported to 5.10: f30f242 ("efi: Rename arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c] Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT flag that can be passed to efi_enabled() to find out whether secure boot is enabled. Move the switch-statement in x86's setup_arch() that inteprets the secure_boot boot parameter to generic code and set the bit there. Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> cc: linux-efi@vger.kernel.org [rperier: Forward-ported to 5.5: - Use pr_warn() - Adjust context] [bwh: Forward-ported to 5.6: adjust context] [bwh: Forward-ported to 5.7: - Use the next available bit in efi.flags - Adjust context] Signed-off-by: Jonathan Maple <jmaple@ciq.com> Revert "efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode" This reverts commit 4047f887e98539d07d664eaa6699d9c8fb6c0ca4.
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. Based on an earlier patch by David Howells, who wrote the following description: > UEFI Secure Boot provides a mechanism for ensuring that the firmware will > only load signed bootloaders and kernels. Certain use cases may also > require that all kernel modules also be signed. Add a configuration option > that to lock down the kernel - which includes requiring validly signed > modules - if the kernel is secure-booted. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [Salvatore Bonaccorso: After fixing https://bugs.debian.org/956197 the help text for LOCK_DOWN_IN_EFI_SECURE_BOOT was adjusted to mention that lockdown is triggered in integrity mode (https://bugs.debian.org/1025417)] Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. These drivers allow mapping arbitrary memory ranges as MTD devices. This should be disabled to preserve the kernel's integrity when it is locked down. * Add the HWPARAM flag to the module parameters * When slram is built-in, it uses __setup() to read kernel parameters, so add an explicit check security_locked_down() check Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Matthew Garrett <mjg59@google.com> Cc: David Howells <dhowells@redhat.com> Cc: Joern Engel <joern@lazybastard.org> Cc: linux-mtd@lists.infradead.org Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Fedora EFI status status commit 7a60169d168d6aae70aca10b7b71070666068529 commit-source https://gitlab.com/cki-project/kernel-ark/ This adds efi_status_to_str() for use when printing efi_status_t messages, and reworks efi_status_to_err() so that the two use a common list of errors. Upstream Status: RHEL only Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
CONFIG_SPI_MICROCHIP_CORE is no longer a valid config option in 6.18.3 spi: microchip: rename driver file and internal identifiers Upstream 71c814e
Upstream commit 5ba2f0a (mm: introduce deferred freeing for kernel page tables) was backported which adds new config option ASYNC_KERNEL_PGTABLE_FREE. Then upsteam commit e37d5a2 (iommu/sva: invalidate stale IOTLB entries for kernel address space) was backported which selects it by default for x86 configs that have selected IOMMU_SVA (which our x86_64 configs have) iommu/sva: invalidate stale IOTLB entries for kernel address space Upstream e37d5a2
The config dependency on DEVICE_PRIVATE for DRM_GPUSVM was removed, causing it to be selected by default for configs with DRM_XE (like ours). Because DRM_GPUSVM is now enabled, DRM_XE_USERPTR_INVAL_INJECT is valid, but not selected by default. drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE Upstream: bdcdf96 upstream.
ATH9K_AHB now depends on OF to be selected by default. x86_64 configs do not have OF. This is fine since ahb bus is arm only. wifi: ath9k: add OF dependency to AHB upstream: 125e7b3
There are customers that will need this enabled by default
This matches the 6.12 spec
We are defining the product as clk so if we ever need to revoke or deny the cert we can target this specific product
by design, kernel-ark blacklists all modules in modules-extra that have a module alias. Now that qdiscs have their module alias [1], some of them became blacklisted even if we didn't really intend to: move them back to kernel-modules to preserve feature parity with other qdiscs (and previous releases). [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=241a94abcf465ba9363d93168da5ddd47002930f
We don't have that
And define pkgrelease using buildid. .1.1.0.0 is excessive
This comes from kernel-ark and is part of their solution for a kernel variant that should supplant the factory kernel. Since thats not what we want, remove this to avoid any confusion.
Adds Provides and Conflicts tags to kernel-clk6.18-* packages that cannot be parallel installed with stock Rocky kernel packages: - kernel-doc - kernel-headers - kernel-cross-headers - kernel-debuginfo-common - kernel-tools - kernel-tools-libs - kernel-tools-libs-devel - kernel-selftests-internal This allows these packages to satisfy dependencies for stock kernel packages while preventing simultaneous installation.
Introduce %{pkg_suffix} macro (clk%{patchversion}) and use it for:
- package_name: kernel-%{pkg_suffix}
- tool packages: perf, python3-perf, libperf, rtla, rv
Tool packages now named:
- perf-%{pkg_suffix}
- python3-perf-%{pkg_suffix}
- libperf-%{pkg_suffix}
- libperf-%{pkg_suffix}-devel
- rtla-%{pkg_suffix}
- rv-%{pkg_suffix}
- *-debuginfo variants
Each tool package includes:
- Provides: <original-name> = %{specrpmversion}-%{release}
- Conflicts: <original-name>
This prevents parallel installation with stock Rocky kernel tools
while satisfying dependencies for the original package names.
Switch Module.symvers compression from the dynamic %compression macro (xz) to hardcoded gzip -c9, matching the upstream kernel spec. Also fixes the ghost file permissions from 0644 to 0600. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
Inject +%{pkg_suffix} into KVERREL and the shell-level equivalents
(KernelVer, DevelDir, EXTRAVERSION) so that uname -r shows the CLK
kernel identity, e.g. 6.18.19-1.1.el9_ciq.x86_64+clk6.18.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
…g boot default Reduce duplicated version numbers in the spec to single sources of truth: - kernel_major_minor, kernel_patch, and buildid are the base defines - specversion, kversion, patchlevel, pkgrelease, specrelease, and tarfile_release are all derived from them - Remove specrpmversion (identical to specversion) - Add el_version for tarball naming Export GRUB_NON_STANDARD_KERNEL=true in the posttrans before calling kernel-install so that 20-grub.install respects DEFAULTKERNEL in /etc/sysconfig/kernel. When DEFAULTKERNEL=kernel-core, the CLK kernel will no longer take over as the boot default on upgrade. Update generate_tarball.sh to extract the base defines and compute derived values rather than reading the now-derived tarfile_release directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
The UKI packages unconditionally required systemd >= 254-1, making them
uninstallable on Rocky 9 which ships systemd 252. The required
kernel-install UKI support (90-uki-copy.install, --entry-type) was
backported to RHEL/Rocky 9's systemd 252-31.
Add the same %{?rhel} conditional that the 6.12 spec uses: require
systemd >= 252-31 on RHEL, >= 254-1 elsewhere.
Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
- Kpatch and driver (DUP) certs should be embedded in all builds - official and local (unsigned) - No version increment here - this change doesn't affect any releases, only local builds
Replace the hardcoded el_version with %{rhel} directly, which is set
automatically by the buildroot. This allows the same branch to produce
el9 packages in a Rocky 9 mock and el10 packages in a Rocky 10 mock.
Update generate_tarball.sh to accept the el version as an optional CLI
argument (e.g. ./generate_tarball.sh 10), falling back to rpm --eval
'%{rhel}' when not specified.
On Rocky 10, use the system bindgen-cli package (available in CRB)
instead of building from the bundled source tarball.
Extend the RPM Build CI workflow to validate builds for both Rocky 9
and Rocky 10 by adding el_version as a matrix dimension.
local_unlock() is supposed to take a percpu pointer, which it then offsets for the current CPU. The problem is that the per-CPU DRBG code passes local_unlock() a pointer that has *already been offset for the current CPU*, so the percpu offset gets added twice. `pcri` is the percpu pointer and `cri` is the offset `pcri` pointer for the current CPU; passing `cri` to local_unlock() results in the current CPU's offset getting added again and thus the resulting pointer is garbage. This went unnoticed at runtime because local_unlock() only dereferences that pointer on PREEMPT_RT or CONFIG_DEBUG_LOCK_ALLOC=y kernels. The pointer is never actually used otherwise. This also went unnoticed at compile time because, for x86_64, __percpu only expands to something on GCC 14+; __percpu is otherwise an empty macro. So there's no pointer type mismatch detected at compile time on older GCC versions. On GCC 14+, the following compile error occurs: ../crypto/rng.c: In function 'lock_default_rng': ../include/linux/percpu-defs.h:221:45: error: initialization from pointer to non-enclosed address space Fix it by using __local_unlock() instead, which eliminates the duplicate per-CPU offset addition. While using local_unlock() with `pcri` also works, using `cri` with __local_unlock() is leaner because it doesn't need to redo the offset addition, saving an instruction on kernels that actually use the pointer. Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
commit-author Jordan Rife <jordan@jrife.io> commit 509ca54 We have several use cases where a pod injects traffic into the datapath of another so that the traffic appears to have originated from that pod. One such use case is a synthetic flow generator which injects synthetic traffic into a pod's datapath to enable dynamic probing and debugging. Another is a transparent proxy where connections originating from one pod are redirected towards another which proxies that connection. The new connection is bound to the IP of the original pod using IP_TRANSPARENT and its traffic is injected into that pod's datapath and handled as if it had originated there. This can be used for mTLS, etc. We use bpf_redirect(BPF_F_INGRESS) to direct traffic leaving the proxy, flow generator, etc. towards the target pod, ensuring that eBPF programs that are meant to intercept traffic leaving that pod are executed. However, this doesn't work with netkit. With netkit, an ingress redirection from proxy to workload skips eBPF programs that are meant to intercept traffic leaving the pod, since they reside on the netkit peer device. One workaround is to attach the same program to both the netkit peer device and the TCX ingress hook for the netkit pair's primary interface, but a) This seems hacky and we need to be careful not to run the same program twice for the same skb in cases where we want to pass that traffic to the host stack. b) We're trying to keep the proxy redirection / traffic injection systems as modular and separated from Cilium as possible, the system that manages netkit setup and core eBPF programming. It would be handy if instead we could redirect traffic directly from one netkit peer device to another. This patch proposes an extension to bpf_redirect_peer to allow us to do just that. With this patch, the BPF_F_EGRESS flag tells bpf_redirect_peer to emit the skb in the egress direction of the target interface's peer device While the main use case is netkit, I suppose you could also use this mode with veth as well if, e.g., there were some eBPF programs attached to that side of the veth pair that needed to intercept traffic. +---------------------------------------------------------------------+ | +-------------------------+ 6. bpf_redirect_neigh(eth0) | | | pod (10.244.0.10) | ------------------------ | | | | | | | | | +--------+ | | +---------+ | | | | 1. packet -->| | | | | | | | | | leaves ^ | netkit |<===========|======| netkit | | | | | | | peer |=======(eBPF)=====>| primary | | | | | | | | | | | | | | | | | +--------+ | | +---------+ | | | | | | | 2. bpf_redirect v | | +-----------|-------------+ |___________________ +-------| | | | | eth0 | | | 5. bpf_redirect_peer(BPF_F_EGRESS) | +-------| | |________________________ | | | +-------------------------+ | | | | | proxy (10.244.0.11) | | | | | | IP_TRANSPARENT | | | | | | +--------+ | | +---------+ | | | | 3. packet <--| | | | | |<-- | | | enters | netkit |<===========|======| netkit | | | | [proxy] | peer |=======(eBPF)=====>| primary | | | | 4. packet -->| | | | | | | | leaves +--------+ | +---------+ | | | sip=10.244.0.10 | | | +-------------------------+ | +---------------------------------------------------------------------+ Using the proxy use case as an example, in step 5 we would redirect traffic leaving the proxy towards the pod's peer device using bpf_redirect_peer(BPF_F_EGRESS). As a bonus, since the skb doesn't have to go through the backlog queue it can take full advantage of netkit's performance benefits. I set up a test where outgoing iperf3 traffic is injected into the datapath of another pod using either bpf_redirect_peer(BPF_F_EGRESS) or bpf_redirect(BPF_F_INGRESS). I used Cilium's eBPF host routing mode which skips the host stack and uses BPF redirect helpers to do all the routing. (net.ipv4.tcp_congestion_control=cubic,mtu=1500,100GiB link,Cilium eBPF host routing mode) BASELINE [bpf_redirect(BPF_F_INGRESS)] 1. [iperf pod] ==bpf_redirect([pod b], BPF_F_INGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 231 GBytes 33.0 Gbits/sec 12060 sender [ 5] 0.00-60.00 sec 230 GBytes 33.0 Gbits/sec receiver TEST [bpf_redirect_peer(BPF_F_EGRESS)] 1. [iperf pod] ==bpf_redirect_peer([pod b], BPF_F_EGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec receiver In this test, using bpf_redirect_peer(BPF_F_EGRESS) for the hop from [iperf pod] to [pod b] led to ~18% more throughput compared to bpf_redirect(BPF_F_INGRESS). Signed-off-by: Jordan Rife <jordan@jrife.io> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://lore.kernel.org/r/20260618182035.43811-2-jordan@jrife.io Signed-off-by: Alexei Starovoitov <ast@kernel.org> (cherry picked from commit 509ca54) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Jordan Rife <jordan@jrife.io> commit 006b945 Extend redirect tests to cover bpf_redirect_peer(BPF_F_EGRESS). SRC redirects to DST using bpf_redirect_peer(BPF_F_EGRESS) then traffic is hairpinned into DST using bpf_redirect. Signed-off-by: Jordan Rife <jordan@jrife.io> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260618182035.43811-3-jordan@jrife.io Signed-off-by: Alexei Starovoitov <ast@kernel.org> (cherry picked from commit 006b945) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Daniel Borkmann <daniel@iogearbox.net> commit 3f4920d upstream-diff | This fix went through the net tree before the BPF_F_EGRESS feature (commit 509ca54) landed via bpf-next, so upstream rejects all flags in bpf_redirect_peer(). This tree already carries BPF_F_EGRESS, so the guard is adjusted to match the resolution in mainline merge commit 4748a67. The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it. Fixes: 401cb7d ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Fixes: 3625750 ("net: sched: Introduce helpers for qevent blocks") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20260706185609.330006-2-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 3f4920d) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Jakub Kicinski <kuba@kernel.org> commit 699f47e Commit ba9db6f ("net: clear the dst when changing skb protocol") added dst clearing when a BPF program changes the skb protocol (e.g. IPv4 to IPv6). Since that was a fix we only cleared the dst when the L3 protocol actually changes to keep it minimal. As suggested during the discussion (see Link) encap or decap operation which wraps or unwraps a same-protocol header may also render the existing dst incorrect - even if that doesn't result in a crash, just the wrong route for the now-outermost IP dst. Make dropping dst unconditional for bpf_skb_change_proto() and all L3 encap / decap ops. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/CANP3RGfRaYwve_xgxH6Tp2zenzKn2-DjZ9tg023WVzfdJF3p_w@mail.gmail.com Link: https://patch.msgid.link/20260329180428.2657785-1-kuba@kernel.org (cherry picked from commit 699f47e) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit 5e4bcad The existing anonymous enum for BPF_FUNC_skb_adjust_room flags is named to enum bpf_adj_room_flags to enable CO-RE (Compile Once - Run Everywhere) lookups in BPF programs. Co-developed-by: Max Tottenham <mtottenh@akamai.com> Co-developed-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Max Tottenham <mtottenh@akamai.com> Signed-off-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/20260812083115.73100-2-nhudson@akamai.com (cherry picked from commit 5e4bcad) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit 7b2ea11 Refactor the helper masks for bpf_skb_adjust_room() flags to simplify validation logic and introduce: - BPF_F_ADJ_ROOM_ENCAP_MASK - BPF_F_ADJ_ROOM_DECAP_MASK Refactor existing validation checks in bpf_skb_net_shrink() and bpf_skb_adjust_room() to use the new masks (no behavior change). This is in preparation for supporting the new decap flags. Co-developed-by: Max Tottenham <mtottenh@akamai.com> Co-developed-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Max Tottenham <mtottenh@akamai.com> Signed-off-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/20260812083115.73100-3-nhudson@akamai.com (cherry picked from commit 7b2ea11) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit da19907 Add new bpf_skb_adjust_room() decapsulation flags: - BPF_F_ADJ_ROOM_DECAP_L4_GRE - BPF_F_ADJ_ROOM_DECAP_L4_UDP - BPF_F_ADJ_ROOM_DECAP_IPXIP4 - BPF_F_ADJ_ROOM_DECAP_IPXIP6 These flags let BPF programs describe which tunnel layer is being removed, so later changes can update tunnel-related GSO state accordingly during decapsulation. This patch only introduces the UAPI flag definitions and helper documentation. Co-developed-by: Max Tottenham <mtottenh@akamai.com> Co-developed-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Max Tottenham <mtottenh@akamai.com> Signed-off-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/20260812083115.73100-4-nhudson@akamai.com (cherry picked from commit da19907) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit 3a39c21 Add checks to require shrink-only decap, reject conflicting decap flag combinations, and verify removed length is sufficient for claimed header decapsulation. Co-developed-by: Max Tottenham <mtottenh@akamai.com> Co-developed-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Max Tottenham <mtottenh@akamai.com> Signed-off-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/20260812083115.73100-5-nhudson@akamai.com (cherry picked from commit 3a39c21) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit ec20dee On shrink in bpf_skb_adjust_room(), apply decapsulation state updates according to BPF_F_ADJ_ROOM_DECAP_* flags. For GSO skbs, clear only the tunnel gso_type bits that correspond to the requested decap layer: - DECAP_L4_UDP: SKB_GSO_UDP_TUNNEL{,_CSUM} - DECAP_L4_GRE: SKB_GSO_GRE{,_CSUM} - DECAP_IPXIP4: SKB_GSO_IPXIP4 - DECAP_IPXIP6: SKB_GSO_IPXIP6 Then clear skb->encapsulation only if no tunnel GSO bits remain, keeping encapsulation set for cases such as ESP-in-UDP where tunnel state remains. For non-GSO skbs, there are no tunnel GSO bits to consult, so clear skb->encapsulation directly when DECAP_L4_* or DECAP_IPXIP_* flags are set. This keeps decap state handling consistent between GSO and non-GSO packets. Co-developed-by: Max Tottenham <mtottenh@akamai.com> Co-developed-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Max Tottenham <mtottenh@akamai.com> Signed-off-by: Anna Glasgall <aglasgal@akamai.com> Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/bpf/20260812083115.73100-6-nhudson@akamai.com (cherry picked from commit ec20dee) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
commit-author Nick Hudson <nhudson@akamai.com> commit adb7719 upstream-diff | The upstream patch targets bpf-next where the BPF program has been converted to use vmlinux.h (commit 86433db) and the test runner has been migrated from a shell script to a C-based test_progs harness (commit 8517b1a). This tree has neither of those prerequisites, so the following upstream changes were dropped: - Post-decap GSO gso_type and skb->encapsulation validation via bpf_cast_to_kern_ctx/bpf_core_cast into skb_shared_info. These require vmlinux.h to access kernel-internal structs (sk_buff, skb_shared_info) and SKB_GSO_* constants. - TSO disable removal from prog_tests/test_tc_tunnel.c (file absent; this tree still uses test_tc_tunnel.sh). The CO-RE enum existence checks, functional flag-passing changes (DECAP_L4_GRE, DECAP_L4_UDP, DECAP_IPXIP4, DECAP_IPXIP6), and ipxip_flag parameter plumbing through decap_internal/decap_ipv4/ decap_ipv6 are applied as in upstream. The test exercises the new kernel flag acceptance path and will fail to load on kernels lacking the new enum values, but does not validate post-decap skb state. tc_tunnel only partially validated decap state and missed some tunnel cases. In particular, IPXIP decap checks were not exercised for IPIP/SIT paths, and non-GSO decap encapsulation state was not verified. Tighten the test by: - setting DECAP_IPXIP4/6 flags for IPIP/SIT/IP6 decap paths based on the outer tunnel header family; - requiring needed DECAP enum values via CO-RE enum existence checks so missing kernel support fails fast; - validating post-decap tunnel state for both GSO and non-GSO packets: expected gso_type bits must be cleared and skb->encapsulation must match remaining tunnel flags; - removing forced TSO disable in the test harness so GSO validation is exercised. This improves coverage for decap tunnel-state regressions and ensures sit_none/ipip-style paths are checked correctly. Signed-off-by: Nick Hudson <nhudson@akamai.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260812083115.73100-7-nhudson@akamai.com (cherry picked from commit adb7719) Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
CXL_RAS was added as a def_bool y depending on ACPI_APEI_GHES, PCIEAER, and CXL_PCI. cxl/pci: Remove CXL VH handling in CONFIG_PCIEAER_CXL conditional blocks from core/pci.c Upstream: 7ff8b1d GPU_BUDDY and GPU_BUDDY_KUNIT_TEST were added and DRM_LIB_RANDOM was removed as the DRM buddy allocator was moved up to drivers/gpu/. DRM_BUDDY now selects GPU_BUDDY, and GPU_BUDDY_KUNIT_TEST defaults to KUNIT_ALL_TESTS. gpu: Move DRM buddy allocator one level up (part two) Upstream: ba110db EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS was added (default 16) to cap the LZMA decompression stream pool size on high-CPU systems. erofs: cap LZMA stream pool size Upstream: c9b47e6
ciq-kernel-automation
Bot
added
the
created-by-kernelci
Author
|
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
12 participants
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.
Summary
This PR has been automatically created after successful completion of all CI stages.
Commit Message(s)
Test Results
✅ Build Stage
✅ Boot Verification
✅ Kernel Selftests
✅ LTP Results
x86_64 regressions:
🤖 This PR was automatically generated by GitHub Actions
Run ID: 34947928439