summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-11PCI: intel-gw: Fix ATU base address setup and add optional DT 'atu' regionFlorian Eckert
The ATU base address was set in intel_pcie_host_setup(), which is called via pp->ops->init(). However, dw_pcie_get_resources() runs before this callback and sets a default atu_base of 0x300000, which then gets overwritten by the driver's value of 0xC0000. But this ordering is broken because atu_base must be set before dw_pcie_get_resources() runs, not after. So move the atu_base assignment from intel_pcie_host_setup() to intel_pcie_probe() to fix the initialization order. The call stack is: intel_pcie_probe dw_pcie_host_init dw_pcie_host_get_resources dw_pcie_get_resources <- sets atu_base = 0x300000 pp->ops->init intel_pcie_rc_init intel_pcie_host_setup <- was overwriting atu_base here Additionally, add support for parsing the ATU region from the device tree. If an 'atu' region is present in DT, the DWC core parses it via dw_pcie_get_resources() and the driver does not set atu_base explicitly. If 'atu' is absent, the driver falls back to the hardcoded offset (0xC0000 from DBI base) for backwards compatibility, with a warning to the user. Signed-off-by: Florian Eckert <fe@dev.tdt.de> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-6-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Add .start_link() callbackFlorian Eckert
The pcie-intel-gw driver had no .start_link() callback. Add one so the driver works again and does not abort with the following error messages during probing: intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges: intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000 intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode intel-gw-pcie d1000000.pcie: No outbound iATU found intel-gw-pcie d1000000.pcie: Cannot initialize host intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22 intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges: intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000 intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode intel-gw-pcie c1100000.pcie: No outbound iATU found intel-gw-pcie c1100000.pcie: Cannot initialize host intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22 Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"") Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: remove timestamps] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-5-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Enable clock before PHY initFlorian Eckert
To ensure that the boot sequence is correct, the DWC PCIe core clock must be switched on before PHY init call [1]. This changes are based on patched kernel sources of the MaxLinear SDK. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-4-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Move interrupt enable to own functionFlorian Eckert
To improve the readability of the code, move the interrupt enable instructions to a separate function. That is already done for the disable interrupt instruction. In addition, clear and disable all pending interrupts, as is done in intel_pcie_core_irq_disable(). After that, enable all relevant interrupts again. The 'PCIE_APP_IRNEN' definition contains all the relevant interrupts that are of interest. This change is also done in the MaxLinear SDK [1]. As I unfortunately don’t have any documentation for this IP core, I suspect that the intention is to set the IP core for interrupt handling to a specific state. Perhaps the problem is that the IP core did not reinitialize the interrupt register properly after a power cycle. In my view, it can’t do any harm to switch the interrupt off and then on again to set them to a specific state. The reason why the MaxLinear SDK is used as a reference here is, that this PCIe DWC IP is used in the URX851 and URX850 SoC. This SoC was originally developed by Intel when they acquired Lantiq’s home networking division in 2015 [2]. In 2020 the home network division was sold to MaxLinear [3]. Since then, this SoC belongs to MaxLinear. They use their own SDK, which runs on kernel version '5.15.x'. [1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431 [2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home [3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-3-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Remove unused PCIE_APP_INTX_OFST definitionFlorian Eckert
The C preprocessor define 'PCIE_APP_INTX_OFST' is not used in the sources. Delete it. Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-2-0a2b933fe04f@dev.tdt.de
2026-05-11arm64: dts: qcom: ipq9650: add watchdog nodeKathiravan Thirumoorthy
Add the watchdog device node for IPQ9650 SoC. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260511-ipq9650_wdt-v1-1-1948934c1e12@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11arm64: dts: qcom: add IPQ9650 SoC and rdp488 board supportKathiravan Thirumoorthy
Add initial device tree support for the Qualcomm IPQ9650 SoC and rdp488 board. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-4-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11dt-bindings: qcom: add IPQ9650 boardsKathiravan Thirumoorthy
Document the new IPQ9650 SoC/board device tree bindings. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-3-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11Merge branch ↵Bjorn Andersson
'20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com' into arm64-for-7.2 Merge the QCS9650 GCC DeviceTree binding from topic branch, to get access to clock and reset constants.
2026-05-11clk: qcom: add Global Clock controller (GCC) driver for IPQ9650 SoCKathiravan Thirumoorthy
Add support for the global clock controller found on IPQ9650 SoC. Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-2-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11Merge branch ↵Bjorn Andersson
'20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com' into clk-for-7.2 Merge the IPQ9650 GCC DeviceTree binding, to allow constants to be made available to DeviceTree source tree as well.
2026-05-11dt-bindings: clock: add Qualcomm IPQ9650 GCCKathiravan Thirumoorthy
Add binding for the Qualcomm IPQ9650 Global Clock Controller. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-11MAINTAINERS: Remove Chuanhua Lei as PCIe intel-gw maintainerFlorian Eckert
Chuanhua Lei's email address has been bouncing for months. Remove the entry and mark the PCI intel-gw driver as orphaned. Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-1-0a2b933fe04f@dev.tdt.de
2026-05-11selftests/bpf: Use both hrtimer enqueue helpers in vmlinux testIhor Solodrai
The vmlinux selftest triggers nanosleep and checks that both kprobe and fentry programs observe the hrtimer enqueue path. After the hrtimer_start_expires_user() conversion [1], nanosleep reaches hrtimer_start_range_ns_user() instead of hrtimer_start_range_ns(). Hard-coding either symbol makes the test fail either on bpf tree or on linux-next [2]. Update the test to resolve the target symbol at runtime via libbpf_find_vmlinux_btf_id(). This is a nice example of how to modify a BPF program to work on both older and newer kernel revision. [1] https://lore.kernel.org/all/20260408114952.062400833@kernel.org/ [2] https://github.com/kernel-patches/bpf/actions/runs/25485909958/job/74782902203 Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260509005730.250956-1-ihor.solodrai@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11hfsplus: rework hfsplus_readdir() logicViacheslav Dubeyko
The xfstests' test-case generic/637 fails with error: FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc4+ #8 SMP PREEMPT_DYNAMIC Thu May 1 16:43:22 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch QA output created by 637 entries 7 and 8 have duplicate d_off 8 Found unlinked files in open dir (see xfstests-dev/results//generic/637.full for details) Debugging of the hfsplus_readdir() logic showed this: hfsplus: hfsplus_readdir(): 163 ctx->pos 0 hfsplus: hfsplus_readdir(): 189 ctx->pos 1 hfsplus: hfsplus_readdir(): 264 ctx->pos 2, ino 18 hfsplus: hfsplus_readdir(): 264 ctx->pos 3, ino 19 hfsplus: hfsplus_readdir(): 264 ctx->pos 4, ino 28 hfsplus: hfsplus_readdir(): 264 ctx->pos 5, ino 118 hfsplus: hfsplus_readdir(): 264 ctx->pos 6, ino 29 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 30 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 31 hfsplus: hfsplus_readdir(): 304 ctx->pos 8 hfsplus: hfsplus_unlink():420 dir->i_ino 17, inode->i_ino 28 hfsplus: hfsplus_readdir(): 141 ctx->pos 7 hfsplus: hfsplus_readdir(): 264 ctx->pos 7, ino 31 hfsplus: hfsplus_readdir(): 264 ctx->pos 8, ino 32 hfsplus: hfsplus_readdir(): 264 ctx->pos 9, ino 33 It means that hfsplus_readdir() stopped the processing of folder's items on ctx->pos 8, then, item with ino 28 has been deleted and hfsplus_readdir() re-started the logic from ctx->pos 7. As a result, previous and new sets of folder's items have overlapping values for the case of d_off 8. Currently, HFS+ has very complicated and fragile logic of rd->file->f_pos correction in hfsplus_delete_cat(). This patch removes this logic and it stores the current pos into hfsplus_readdir_data. Finally, if rd->pos == ctx->pos then hfsplus_readdir() tries to find the position in b-tree's node by means of hfsplus_cat_key. This position is used to re-start the folder's content traversal. sudo ./check generic/637 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 7.1.0-rc1+ #44 SMP PREEMPT_DYNAMIC Mon May 4 15:58:45 PDT 2026 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch generic/637 22s ... 22s Ran: generic/637 Passed all 1 tests Closes: https://github.com/hfs-linux-kernel/hfs-linux-kernel/issues/198 cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> cc: Yangtao Li <frank.li@vivo.com> cc: linux-fsdevel@vger.kernel.org Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com> Link: https://lore.kernel.org/r/20260505220051.2854696-2-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
2026-05-12zonefs: handle integer overflow in zonefs_fname_to_fnoJohannes Thumshirn
In zonefs the file name in one of the two directories corresponds to the zone number. Here Alexey reported a possible integer overflow in zonefs_fname_to_fno(), where the parsing of the zone number from the file name can overflow the 'long' data type. Add a check for integer overflows and if the fno 'long' did overflow return -ENOENT. Reported-by: Alexey Dobriyan <adobriyan@gmail.com> Fixes: d207794ababe ("zonefs: Dynamically create file inodes when needed") Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-05-11Merge branch 'for-7.1-fixes' into for-7.2Tejun Heo
Pull to receive: 9a415cc53711 ("sched_ext: Avoid UAF in scx_root_enable_workfn() init failure path") Conflicts with for-7.2's scx_task_iter_relock() rework. The fix moves put_task_struct(p) past scx_error(); for-7.2 still has it at the old position. Resolved by dropping the old one. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-11Merge tag 'linux_kselftest-kunit-fixes-7.1-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kunit fixes from Shuah Khan: "Fix to decouple KUNIT_DEBUGFS and KUNIT_ALL_TESTS options and fix KUNIT_DEBUGFS dependencies so it depends on DEBUG_FS without which it will not be useful" * tag 'linux_kselftest-kunit-fixes-7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: config: KUNIT_DEBUGFS should depend on DEBUG_FS kunit: config: Enable KUNIT_DEBUGFS by default
2026-05-11Merge branch 'selftests-bpf-add-xdp-load-balancer-benchmark'Alexei Starovoitov
Puranjay Mohan says: ==================== selftests/bpf: Add XDP load-balancer benchmark Changelog: RFC: https://lore.kernel.org/all/20260420111726.2118636-1-puranjay@kernel.org/ Changes in v1: - Replace bpf_get_cpu_time_counter() with bpf_ktime_get_ns() - Replace bpf_repeat() with plain for loop and may_goto - Refactor collect_measurements() to reuse bench_force_done() - Remove histogram, verbose calibration output, and per-scenario status prints - Trim run script table to p50/stddev/p99 - Set env.quiet when --machine-readable is passed - Add || true to run script benchmark invocation for set -e safety - Add bpf-nop benchmark as timing overhead baseline (patch 3) - Use named struct for LRU inner map to fix build on older toolchains This series adds an XDP load-balancer benchmark (based on Katran) to the BPF selftest bench framework. Motivation ---------- Existing BPF bench tests measure individual operations (map lookups, kprobes, ring buffers) in isolation. Production BPF programs combine parsing, map lookups, branching, and packet rewriting in a single call chain. The performance characteristics of such programs depend on the interaction of these operations -- register pressure, spills, inlining decisions, branch layout -- which isolated micro-benchmarks do not capture. This benchmark implements a simplified L4 load-balancer modeled after katran [1]. The BPF program reproduces katran's core datapath: L3/L4 parsing -> VIP hash lookup -> per-CPU LRU connection table with consistent-hash fallback -> real server selection -> per-VIP and per-real stats -> IPIP/IP6IP6 encapsulation The BPF code exercises hash maps, array-of-maps (per-CPU LRU), percpu arrays, jhash, bpf_xdp_adjust_head(), bpf_ktime_get_ns(), and bpf_get_smp_processor_id() in a single pipeline. This is intended as the first in a series of BPF workload benchmarks covering other use cases (sched_ext, etc.). Design ------ A userspace loop calling bpf_prog_test_run_opts(repeat=1) would measure syscall overhead, not BPF program cost -- the ~4 ns early-exit paths would be buried under kernel entry/exit. Using repeat=N is also unsuitable: the kernel re-runs the same packet without resetting state between iterations, so the second iteration of an encap scenario would process an already-encapsulated packet. Instead, timing is measured inside the BPF program using bpf_ktime_get_ns(). BENCH_BPF_LOOP() brackets N iterations with timestamp reads using a plain for loop with may_goto, runs a caller-supplied reset block between iterations to undo side effects (e.g. strip encapsulation), and records the elapsed time per batch. One extra untimed iteration runs afterward for output validation. Auto-calibration picks a batch size targeting ~10 ms per invocation. A proportionality sanity check verifies that 2N iterations take ~2x as long as N. 24 scenarios cover the code-path matrix: - Protocol: TCP, UDP - Address family: IPv4, IPv6, cross-AF (IPv4-in-IPv6) - LRU state: hit, miss (16M flow space), diverse (4K flows), cold - Consistent-hash: direct (LRU bypass) - TCP flags: SYN (skip LRU, force CH), RST (skip LRU insert) - Early exits: unknown VIP, non-IP, ICMP, fragments, IP options Each scenario validates correctness before benchmarking by comparing the output packet byte-for-byte against a pre-built expected packet and checking BPF map counters. Sample single-scenario output: $ sudo ./bench xdp-lb --scenario tcp-v4-lru-hit Setting up benchmark 'xdp-lb'... Benchmark 'xdp-lb' started. tcp-v4-lru-hit: median 74.51 ns/op, stddev 0.11, p99 74.81 (202 samples) Sample run script output: $ ./benchs/run_bench_xdp_lb.sh XDP load-balancer benchmark =========================== +----------------------------------+----------+---------+----------+ | Single-flow baseline | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-hit | 74.30 | 0.08 | 74.48 | | tcp-v4-ch | 101.73 | 0.11 | 102.01 | | tcp-v6-lru-hit | 76.77 | 0.14 | 77.04 | | tcp-v6-ch | 121.40 | 0.10 | 121.65 | | udp-v4-lru-hit | 107.42 | 0.22 | 107.90 | | udp-v6-lru-hit | 110.21 | 0.12 | 110.45 | | tcp-v4v6-lru-hit | 74.82 | 0.35 | 75.43 | +----------------------------------+----------+---------+----------+ | Diverse flows (4K src addrs) | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-diverse | 86.63 | 0.37 | 89.04 | | tcp-v4-ch-diverse | 104.09 | 0.19 | 105.67 | | tcp-v6-lru-diverse | 89.34 | 0.42 | 90.70 | | tcp-v6-ch-diverse | 122.20 | 0.21 | 123.78 | | udp-v4-lru-diverse | 119.37 | 0.58 | 123.10 | +----------------------------------+----------+---------+----------+ | TCP flags | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-syn | 165.52 | 15.68 | 198.34 | | tcp-v4-rst-miss | 161.34 | 2.69 | 172.64 | +----------------------------------+----------+---------+----------+ | LRU stress | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | tcp-v4-lru-miss | 440.39 | 35.75 | 550.62 | | udp-v4-lru-miss | 571.88 | 57.38 | 680.61 | | tcp-v4-lru-warmup | 317.75 | 9.55 | 356.20 | +----------------------------------+----------+---------+----------+ | Early exits | p50 | stddev | p99 | +----------------------------------+----------+---------+----------+ | pass-v4-no-vip | 18.26 | 0.13 | 18.66 | | pass-v6-no-vip | 19.08 | 0.01 | 19.10 | | pass-v4-icmp | 6.81 | 0.02 | 6.86 | | pass-non-ip | 5.71 | 0.03 | 5.76 | | drop-v4-frag | 6.09 | 0.01 | 6.10 | | drop-v4-options | 5.88 | 0.00 | 5.89 | | drop-v6-frag | 6.00 | 0.03 | 6.04 | +----------------------------------+----------+---------+----------+ Patches ------- Patch 1 adds bench_force_done() to the bench framework so benchmarks can signal early completion when enough samples have been collected. Patch 2 adds the shared BPF batch-timing library (BPF-side timing arrays, BENCH_BPF_LOOP macro, userspace statistics and calibration). Patch 3 adds a bpf-nop benchmark as a timing overhead baseline and usage example for the timing library. Patch 4 adds the common header shared between the BPF program and userspace (flow_key, vip_definition, real_definition, encap helpers). Patch 5 adds the XDP load-balancer BPF program. Patch 6 adds the userspace benchmark driver with 24 scenarios, packet construction, validation, and bench framework integration. Patch 7 adds the run script for running all scenarios. [1] https://github.com/facebookincubator/katran ==================== Link: https://patch.msgid.link/20260427232313.1582588-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer benchmark run scriptPuranjay Mohan
Add a convenience script that runs all 24 XDP load-balancer scenarios and formats the results as a table with median, stddev, and p99 columns. ./benchs/run_bench_xdp_lb.sh Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-8-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer benchmark driverPuranjay Mohan
Wire up the userspace side of the XDP load-balancer benchmark. 24 scenarios cover the full code-path matrix: TCP/UDP, IPv4/IPv6, cross-AF encap, LRU hit/miss/diverse/cold, consistent-hash bypass, SYN/RST flag handling, and early exits (unknown VIP, non-IP, ICMP, fragments, IP options). Before benchmarking each scenario validates correctness: the output packet is compared byte-for-byte against a pre-built expected packet and BPF map counters are checked against the expected values. Usage: sudo ./bench -a -w3 -p1 xdp-lb --scenario tcp-v4-lru-hit sudo ./bench xdp-lb --list-scenarios Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-7-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer BPF programPuranjay Mohan
Add the BPF datapath for the XDP load-balancer benchmark, a simplified L4 load-balancer inspired by katran. The pipeline: L3/L4 parse -> VIP lookup -> per-CPU LRU connection table or consistent-hash fallback -> real server lookup -> per-VIP and per-real stats -> IPIP/IP6IP6 encapsulation. TCP SYN forces the consistent-hash path (skipping LRU); TCP RST skips LRU insert to avoid polluting the table. process_packet() is marked __noinline so that the BENCH_BPF_LOOP reset block (which strips encapsulation) operates on valid packet pointers after bpf_xdp_adjust_head(). Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-6-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add XDP load-balancer common definitionsPuranjay Mohan
Add the shared header for the XDP load-balancer benchmark. This defines the data structures used by both the BPF program and userspace: flow_key, vip_definition, real_definition, and the stats/control structures. Also provides the encapsulation source-address helpers shared between the BPF datapath (for encap) and userspace (for building expected output packets used in validation). Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-5-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add bpf-nop benchmark for timing overhead baselinePuranjay Mohan
Add a minimal benchmark that measures the overhead of the batch-timing infrastructure itself. The BPF program runs an empty BENCH_BPF_LOOP body (~1.5-2 ns/op), establishing the floor cost that all timing-library benchmarks include. [root@virtme-ng tools/testing/selftests/bpf]# sudo ./bench -a -p8 bpf-nop Setting up benchmark 'bpf-nop'... Benchmark 'bpf-nop' started. bpf-nop: median 1.82 ns/op, stddev 0.01, p99 1.86 (1754 samples) Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-4-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add BPF batch-timing libraryPuranjay Mohan
Add a reusable timing library for BPF benchmarks that need to measure BPF program execution time. The BPF side (progs/bench_bpf_timing.bpf.h) provides per-CPU sample arrays and BENCH_BPF_LOOP(), a macro that brackets batch_iters iterations with bpf_ktime_get_ns() reads and records the elapsed time. One extra untimed iteration runs afterward for output validation. The userspace side (benchs/bench_bpf_timing.c) collects samples from the skeleton BSS, computes percentile statistics, and auto-calibrates batch_iters to target ~10 ms per batch. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11selftests/bpf: Add bench_force_done() for early benchmark completionPuranjay Mohan
The bench framework waits for duration_sec to elapse before collecting results. Benchmarks that know exactly how many samples they need can call bench_force_done() to signal completion early, avoiding wasted wall-clock time. Also refactor collect_measurements() to reuse bench_force_done() instead of open-coding the same mutex/cond_signal sequence. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20260427232313.1582588-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-11sched_ext: Avoid UAF in scx_root_enable_workfn() init failure pathTejun Heo
In scx_root_enable_workfn(), put_task_struct(p) is called before scx_error() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF. Move put_task_struct() past scx_error(). Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260511214031.AF5E9C2BCB0@smtp.kernel.org/ Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-11drm/amdgpu/gfx_v12_0: set gfx.rs64_enable from PFP header on GFX12Jesse Zhang
gfx_v12_0_init_microcode() always loads RS64 CP ucode but never set adev->gfx.rs64_enable, so it stayed false and code that branches on it (e.g. MEC pipe reset) used the legacy CP_MEC_CNTL path incorrectly. Match GFX11: derive RS64 mode from the PFP firmware header (v2.0) via amdgpu_ucode_hdr_version(). Log at debug when RS64 is enabled. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit b03d53598b0d2048e8fa7303b8d0784768ec4fa6)
2026-05-11drm/amd/ras: Fix CPER ring debugfs read overflowXiang Liu
The legacy CPER debugfs reader can reach the payload path without a valid pointer snapshot. The remaining user byte count is also treated as the ring occupancy in dwords, so reads past the header can copy more than requested. Take the CPER lock before sampling pointers. Resample rptr/wptr for payload reads, bound the payload copy by available dwords and the remaining user size, and advance the file position for each dword copied. Signed-off-by: Xiang Liu <xiang.liu@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1e40ef87ffdc291e05ccdade8b9170cc9c1c4249)
2026-05-11drm/amd/display: Wrap DCN32 phantom-plane allocation in ↵Mikhail Gavrilov
DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. Fixes: 235c67634230 ("drm/amd/display: add DCN32/321 specific files for Display Core") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/4470 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: James Lin <pinglei.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11) Cc: stable@vger.kernel.org
2026-05-11drm/amdgpu: fix userq hang detection and resetChristian König
Fix lock inversions pointed out by Prike and Sunil. The hang detection timeout *CAN'T* grab locks under which we wait for fences, especially not the userq_mutex lock. Then instead of this completely broken handling with the hang_detect_fence just cancel the work when fences are processed and re-start if necessary. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1b62077f045ac6ffde7c97005c6659569ac5c1ec)
2026-05-11drm/amdgpu: remove almost all calls to amdgpu_userq_detect_and_reset_queuesChristian König
Well the reset handling seems broken on multiple levels. As first step of fixing this remove most calls to the hang detection. That function should only be called after we run into a timeout! And *NOT* as random check spread over the code in multiple places. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 71bea36b54ccfb14cbc90f94267af6369af4e702)
2026-05-11drm/amdgpu: rework amdgpu_userq_signal_ioctl v3Christian König
This one was fortunately not looking so bad as the wait ioctl path, but there were still a few things which could be fixed/improved: 1. Allocating with GFP_ATOMIC was quite unnecessary, we can do that before taking the userq_lock. 2. Use a new mutex as protection for the fence_drv_xa so that we can do memory allocations while holding it. 3. Starting the reset timer is unnecessary when the fence is already signaled when we create it. 4. Cleanup error handling, avoid trying to free the queue when we don't even got one. v2: fix incorrect usage of xa_find, destroy the new mutex on error v3: cleanup ref ordering Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Sunil Khatri <sunil.khatri@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1609eb0f81a609d350169839128cecf298c84e7a)
2026-05-11drm/amdgpu: remove deadlocks from amdgpu_userq_pre_resetChristian König
The purpose of a GPU reset is to make sure that fence can be signaled again and the signal and resume workers can make progress again. So waiting for the resume worker or any fence in the GPU reset path is just utterly nonsense. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Prike Liang <Prike.Liang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit fcd5f065eab46993af43442fd77ee8d9eb9c5bdf)
2026-05-11sched_ext: Mark !CONFIG_EXT_SUB_SCHED dummy stubs static inlineTejun Heo
Mark !CONFIG_EXT_SUB_SCHED dummy stubs static inline to avoid -Wunused-function in configs without callers. No functional change. Signed-off-by: Tejun Heo <tj@kernel.org>
2026-05-11Merge patch series "proc: subset=pid: Relax check of mount visibility"Christian Brauner
Alexey Gladkov <legion@kernel.org> says: When mounting procfs with the subset=pids option, all static files become unavailable and only the dynamic part with information about pids is accessible. In this case, there is no point in imposing additional restrictions on the visibility of the entire filesystem for the mounter. Everything that can be hidden in procfs is already inaccessible. Currently, these restrictions prevent procfs from being mounted inside rootless containers, as almost all container implementations override part of procfs to hide certain directories. Relaxing these restrictions will allow pidfs to be used in nested containerization. * patches from https://patch.msgid.link/cover.1777278334.git.legion@kernel.org: docs: proc: add documentation about mount restrictions proc: handle subset=pid separately in userns visibility checks proc: prevent reconfiguring subset=pid proc: subset=pid: Show /proc/self/net only for CAP_NET_ADMIN sysfs: remove trivial sysfs_get_tree() wrapper fs: move SB_I_USERNS_VISIBLE to FS_USERNS_MOUNT_RESTRICTED namespace: record fully visible mounts in list Link: https://patch.msgid.link/cover.1777278334.git.legion@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11docs: proc: add documentation about mount restrictionsAlexey Gladkov
procfs has a number of mounting restrictions that are not documented anywhere. Signed-off-by: Alexey Gladkov <legion@kernel.org> Link: https://patch.msgid.link/e7cb804df3c1759ee17cf9df1dc4c211d63d7a5f.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11proc: handle subset=pid separately in userns visibility checksAlexey Gladkov
When procfs is mounted with subset=pid, only the dynamic process-related part of the filesystem remains visible. That part cannot be hidden by overmounts, so checking whether an existing procfs mount is fully visible does not make sense for this mode. At the same time, a subset=pid procfs mount must not be used as evidence that a later procfs mount would not reveal additional information. It provides a restricted view of procfs, not the full filesystem view. Mark subset=pid procfs instances as restricted variants. Ignore restricted variants when looking for an already-visible mount, and allow new restricted variants without consulting mnt_already_visible(). Signed-off-by: Alexey Gladkov <legion@kernel.org> Link: https://patch.msgid.link/4d5e760c3d534dd2e05578d119cc408450053a98.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11proc: prevent reconfiguring subset=pidAlexey Gladkov
Changing subset=pid on an existing procfs instance is not safe. If a full procfs mount has entries hidden by overmounts, switching it to subset=pid would hide the top-level procfs entries from lookup and readdir while leaving the existing overmounts reachable. Reject attempts to change the subset=pid state during reconfigure before applying any other procfs mount options, so a failed reconfigure cannot partially update the instance. Signed-off-by: Alexey Gladkov <legion@kernel.org> Link: https://patch.msgid.link/13295f40f642af5d6e7038d681d43132ad80f7b2.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11Merge patch series "revamp fs/filesystems.c"Christian Brauner
Mateusz Guzik <mjguzik@gmail.com> says: The file is a mess with a hand-rolled linked list in a desperate need of a clean up. The code to emit /proc/filesystems is used frequently because libselinux reads the file, which in turn is linked into numerous frequently used programs (even ones you would not suspect, like sed!). In order to combat that pre-gen the string instead of pointer-chasing and printfing one by-one. open+read+close cycle single-threaded (ops/s): before: 442732 after: 1063462 (+140%) Additionally scalability is also improved thanks to bypassing ref maintenance on open/close. open+read+close cycle with 20 processes (ops/s): before: 606177 after: 3300576 (+444%) The main bottleneck afterwards is the spurious lockref trip on open. * patches from https://patch.msgid.link/20260425220844.1763933-1-mjguzik@gmail.com: fs: cache the string generated by reading /proc/filesystems fs: RCU-ify filesystems list proc: allow to mark /proc files permanent outside of fs/proc/ Link: https://patch.msgid.link/20260425220844.1763933-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11proc: subset=pid: Show /proc/self/net only for CAP_NET_ADMINAlexey Gladkov
Cache the mounters credentials and allow access to the net directories contingent of the permissions of the mounter of proc. Do not show /proc/self/net when proc is mounted with subset=pid option and the mounter does not have CAP_NET_ADMIN. To avoid inadvertently allowing access to /proc/<pid>/net, updating mounter credentials is not supported. Signed-off-by: Alexey Gladkov <legion@kernel.org> Link: https://patch.msgid.link/d2466fe9085367f1e24693c437ecb8cff2789660.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11fs: cache the string generated by reading /proc/filesystemsMateusz Guzik
It is being read surprisingly often (e.g., by mkdir, ls and even sed!). This is lock-protected pointer chasing over a linked list to pay for sprintf for every fs (32 on my boxen). Instead cache the result. While here make the file as permanent to avoid spurious ref trips in procfs. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20260425220844.1763933-4-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11sysfs: remove trivial sysfs_get_tree() wrapperChristian Brauner
Now that FS_USERNS_MOUNT_RESTRICTED is a file_system_type flag, sysfs_get_tree() is a trivial wrapper around kernfs_get_tree() with no additional logic. Point sysfs_fs_context_ops.get_tree directly at kernfs_get_tree() and remove the wrapper. Link: https://patch.msgid.link/e8ac71fc96ad864c8b58fc0a8e5305550c01db25.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11fs: RCU-ify filesystems listChristian Brauner
The drivers list was protected by an rwlock; every mount, every open of /proc/filesystems and the legacy sysfs(2) syscall walked a hand-rolled singly-linked list under it. /proc/filesystems is especially hot because libselinux causes programs as mundane as mkdir, ls and sed to open and read it on every invocation. Convert the list to an RCU-protected hlist and switch the writer side to a plain spinlock. Writers keep their existing non-sleeping section while readers walk under rcu_read_lock() with no lock traffic: - register_filesystem()/unregister_filesystem() take file_systems_lock, publish via hlist_{add_tail,del_init}_rcu() and invalidate the cached /proc/filesystems string. unregister_filesystem() keeps its synchronize_rcu() after dropping the lock so in-flight readers are drained before the module (and its embedded file_system_type) can go away. - __get_fs_type(), list_bdev_fs_names() and the fs_index()/fs_name()/fs_maxindex() helpers walk the list under rcu_read_lock(). fs_name() continues to drop the read-side lock after try_module_get() and accesses ->name outside the RCU section; the module reference pins the embedded file_system_type across the boundary. struct file_system_type::next becomes struct hlist_node list; no in-tree caller references the old ->next field outside fs/filesystems.c. Link: https://patch.msgid.link/20260425220844.1763933-3-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11fs: move SB_I_USERNS_VISIBLE to FS_USERNS_MOUNT_RESTRICTEDChristian Brauner
Whether a filesystem's mounts need to undergo a visibility check in user namespaces is a static property of the filesystem type, not a runtime property of each superblock instance. Both proc and sysfs always set SB_I_USERNS_VISIBLE on their superblocks unconditionally (sysfs does so on first creation, and subsequent mounts reuse the same superblock). Move this flag from sb->s_iflags (SB_I_USERNS_VISIBLE) to file_system_type->fs_flags (FS_USERNS_MOUNT_RESTRICTED) so the intent is expressed at the filesystem type level where it belongs. All check sites are updated to test sb->s_type->fs_flags instead of sb->s_iflags. The SB_I_NOEXEC and SB_I_NODEV flags remain on the superblock as they are runtime properties set during fill_super. Link: https://patch.msgid.link/72887c5b6204dc3adf5a53104f0be6bd8bc4f6cd.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11proc: allow to mark /proc files permanent outside of fs/proc/Alexey Dobriyan
Add proc_make_permanent() function to mark PDE as permanent to speed up open/read/close (one alloc/free and lock/unlock less). Enable it for built-in code and for compiled-in modules. This function becomes nop magically in modular code. Note, note, note! If built-in code creates and deletes PDEs dynamically (not in init hook), then proc_make_permanent() must not be used. It is intended for simple code: static int __init xxx_module_init(void) { g_pde = proc_create_single(); proc_make_permanent(g_pde); return 0; } static void __exit xxx_module_exit(void) { remove_proc_entry(g_pde); } If module is built-in then exit hook never executed and PDE is permanent so it is OK to mark it as such. If module is module then rmmod will yank PDE, but proc_make_permanent() is nop and core /proc code will do everything right. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Link: https://patch.msgid.link/20260425220844.1763933-2-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11namespace: record fully visible mounts in listChristian Brauner
Instead of wading through all the mounts in the mount namespace rbtree to find fully visible procfs and sysfs mounts, be honest about them being special cruft and record them in a separate per-mount namespace list. Link: https://patch.msgid.link/684859a8e0ac929cb89c1fbe16ce15b30c70eb1f.1777278334.git.legion@kernel.org Reviewed-by: Aleksa Sarai <aleksa@amutable.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11fs: retire stale lock ordering annotations from inode hashrefs/merge-window/78fcd640d0bb2c68b3ce6a3ad583b4428310122bMateusz Guzik
1. iunique does not take the hash lock as of: 3f19b2ab97a97b41 ("vfs, afs, ext4: Make the inode hash table RCU searchable") 2. s_inode_list_lock is no longer taken under the hash lock as of: c918f15420e336a9 ("fs: call inode_sb_list_add() outside of inode hash lock") Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20260423170431.1483370-1-mjguzik@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11Merge patch series "assorted ->i_count changes + extension of lockless handling"Christian Brauner
Mateusz Guzik <mjguzik@gmail.com> says: The stock kernel support partial lockless in handling in that iput() can decrement any value > 1. Any ref acquire however requires the spinlock. With this patchset ref acquires when the value was already at least 1 also become lockless. That is, only transitions 0->1 and 1->0 take the lock. I verified when nfs calls into the hash taking the lock is typically avoided. Similarly, btrfs likes to igrab() and avoids the lock. However, I have to fully admit I did not perform any benchmarks. While cleaning stuff up I noticed lockless operation is almost readily available so I went for it. Clean-up wise, the icount_read_once() stuff lines up with inode_state_read_once(). The prefix is different but I opted to not change it due to igrab(), ihold() et al. * patches from https://patch.msgid.link/20260421182538.1215894-1-mjguzik@gmail.com: fs: allow lockless ->i_count bumps as long as it does not transition 0->1 fs: relocate and tidy up ihold() fs: add icount_read_once() and stop open-coding ->i_count loads Link: https://patch.msgid.link/20260421182538.1215894-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-05-11fs: allow lockless ->i_count bumps as long as it does not transition 0->1Mateusz Guzik
With this change only 0->1 and 1->0 transitions need the lock. I verified all places which look at the refcount either only care about it staying 0 (and have the lock enforce it) or don't hold the inode lock to begin with (making the above change irrelevant to their correcness or lack thereof). I also confirmed nfs and btrfs like to call into these a lot and now avoid the lock in the common case, shaving off some atomics. Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Link: https://patch.msgid.link/20260421182538.1215894-4-mjguzik@gmail.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>