- Linux-kselftest-mirror - lists.linaro.org

[PATCH v3 0/3] introduce PIDFD_SELF* sentinels

by Lorenzo Stoakes

If you wish to utilise a pidfd interface to refer to the current process or thread it is rather cumbersome, requiring something like: int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD); ... close(pidfd); Or the equivalent call opening /proc/self. It is more convenient to use a sentinel value to indicate to an interface that accepts a pidfd that we simply wish to refer to the current process thread. This series introduces sentinels for this purposes which can be passed as the pidfd in this instance rather than having to establish a dummy fd for this purpose. It is useful to refer to both the current thread from the userland's perspective for which we use PIDFD_SELF, and the current process from the userland's perspective, for which we use PIDFD_SELF_PROCESS. There is unfortunately some confusion between the kernel and userland as to what constitutes a process - a thread from the userland perspective is a process in userland, and a userland process is a thread group (more specifically the thread group leader from the kernel perspective). We therefore alias things thusly: * PIDFD_SELF_THREAD aliased by PIDFD_SELF - use PIDTYPE_PID. * PIDFD_SELF_THREAD_GROUP alised by PIDFD_SELF_PROCESS - use PIDTYPE_TGID. In all of the kernel code we refer to PIDFD_SELF_THREAD and PIDFD_SELF_THREAD_GROUP. However we expect users to use PIDFD_SELF and PIDFD_SELF_PROCESS. This matters for cases where, for instance, a user unshare()'s FDs or does thread-specific signal handling and where the user would be hugely confused if the FDs referenced or signal processed referred to the thread group leader rather than the individual thread. We ensure that pidfd_send_signal() and pidfd_getfd() work correctly, and assert as much in selftests. All other interfaces except setns() will work implicitly with this new interface, however it doesn't make sense to test waitid(P_PIDFD, ...) as waiting on ourselves is a blocking operation. In the case of setns() we explicitly disallow use of PIDFD_SELF* as it doesn't make sense to obtain the namespaces of our own process, and it would require work to implement this functionality there that would be of no use. We also do not provide the ability to utilise PIDFD_SELF* in ordinary fd operations such as open() or poll(), as this would require extensive work and be of no real use. v3: * Do not fput() an invalid fd as reported by kernel test bot. * Fix unintended churn from moving variable declaration. v2: * Fix tests as reported by Shuah. * Correct RFC version lore link. https://lore.kernel.org/linux-mm/cover.1728643714.git.lorenzo.stoakes@oracl… Non-RFC v1: * Removed RFC tag - there seems to be general consensus that this change is a good idea, but perhaps some debate to be had on implementation. It seems sensible then to move forward with the RFC flag removed. * Introduced PIDFD_SELF_THREAD, PIDFD_SELF_THREAD_GROUP and their aliases PIDFD_SELF and PIDFD_SELF_PROCESS respectively. * Updated testing accordingly. https://lore.kernel.org/linux-mm/cover.1728578231.git.lorenzo.stoakes@oracl… RFC version: https://lore.kernel.org/linux-mm/cover.1727644404.git.lorenzo.stoakes@oracl… Lorenzo Stoakes (3): pidfd: extend pidfd_get_pid() and de-duplicate pid lookup pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process selftests: pidfd: add tests for PIDFD_SELF_* include/linux/pid.h | 43 +++++- include/uapi/linux/pidfd.h | 15 ++ kernel/exit.c | 3 +- kernel/nsproxy.c | 1 + kernel/pid.c | 73 ++++++--- kernel/signal.c | 26 +--- tools/testing/selftests/pidfd/pidfd.h | 8 + .../selftests/pidfd/pidfd_getfd_test.c | 141 ++++++++++++++++++ .../selftests/pidfd/pidfd_setns_test.c | 11 ++ tools/testing/selftests/pidfd/pidfd_test.c | 76 ++++++++-- 10 files changed, 342 insertions(+), 55 deletions(-) -- 2.46.2

6 months

6
31
0 0

[PATCH 0/8] stackleak: Support Clang stack depth tracking

by Kees Cook

Hi, As part of looking at what GCC plugins could be replaced with Clang implementations, this series uses the recently landed stack depth tracking callback in Clang[1] to implement the stackleak feature. Since the Clang feature is now landed, I'm moving this out of RFC to a v1. Since this touches a lot of arch-specific Makefiles, I tried to trim the CC list down to just mailing lists in those cases, otherwise the CC was giant. Thanks! -Kees [1] https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-stack-depth v1: - Finalize Clang URLs for landed feature - Perform CFLAGS enabling more sanely, as done for randstruct - Split __no_sanitize_coverage into separate patch - Update hardening.config and MAINTAINERS - Fix bug found with nvme tree RFC: https://lore.kernel.org/lkml/20250502185834.work.560-kees@kernel.org/ Kees Cook (8): nvme-pci: Make nvme_pci_npages_prp() __always_inline init.h: Disable sanitizer coverage for __init and __head stackleak: Rename CONFIG_GCC_PLUGIN_STACKLEAK to CONFIG_STACKLEAK stackleak: Rename stackleak_track_stack to __sanitizer_cov_stack_depth stackleak: Split STACKLEAK_CFLAGS from GCC_PLUGINS_CFLAGS stackleak: Support Clang stack depth tracking configs/hardening: Enable CONFIG_STACKLEAK configs/hardening: Enable CONFIG_INIT_ON_FREE_DEFAULT_ON security/Kconfig.hardening | 25 ++++++---- Makefile | 1 + arch/arm/boot/compressed/Makefile | 2 +- arch/arm/vdso/Makefile | 2 +- arch/arm64/kernel/pi/Makefile | 2 +- arch/arm64/kernel/vdso/Makefile | 3 +- arch/arm64/kvm/hyp/nvhe/Makefile | 2 +- arch/riscv/kernel/pi/Makefile | 2 +- arch/riscv/purgatory/Makefile | 2 +- arch/sparc/vdso/Makefile | 3 +- arch/x86/entry/vdso/Makefile | 3 +- arch/x86/purgatory/Makefile | 2 +- drivers/firmware/efi/libstub/Makefile | 6 +-- kernel/Makefile | 4 +- lib/Makefile | 2 +- scripts/Makefile.gcc-plugins | 16 +------ scripts/Makefile.stackleak | 21 +++++++++ scripts/gcc-plugins/stackleak_plugin.c | 52 ++++++++++----------- Documentation/admin-guide/sysctl/kernel.rst | 2 +- Documentation/security/self-protection.rst | 2 +- arch/x86/entry/calling.h | 4 +- arch/x86/include/asm/init.h | 2 +- include/linux/init.h | 4 +- include/linux/sched.h | 4 +- include/linux/stackleak.h | 6 +-- arch/arm/kernel/entry-common.S | 2 +- arch/arm64/kernel/entry.S | 2 +- arch/riscv/kernel/entry.S | 2 +- arch/s390/kernel/entry.S | 2 +- drivers/misc/lkdtm/stackleak.c | 8 ++-- drivers/nvme/host/pci.c | 2 +- kernel/stackleak.c | 4 +- tools/objtool/check.c | 2 +- tools/testing/selftests/lkdtm/config | 2 +- MAINTAINERS | 6 ++- kernel/configs/hardening.config | 6 +++ 36 files changed, 122 insertions(+), 90 deletions(-) create mode 100644 scripts/Makefile.stackleak -- 2.34.1

6 months

5
14
0 0

[PATCH net] net: Lock lower level devices when updating features

by Cosmin Ratiu

__netdev_update_features() expects the netdevice to be ops-locked, but it gets called recursively on the lower level netdevices to sync their features, and nothing locks those. This commit fixes that, with the assumption that it shouldn't be possible for both higher-level and lover-level netdevices to require the instance lock, because that would lead to lock dependency warnings. Without this, playing with higher level (e.g. vxlan) netdevices on top of netdevices with instance locking enabled can run into issues: WARNING: CPU: 59 PID: 206496 at ./include/net/netdev_lock.h:17 netif_napi_add_weight_locked+0x753/0xa60 [...] Call Trace: <TASK> mlx5e_open_channel+0xc09/0x3740 [mlx5_core] mlx5e_open_channels+0x1f0/0x770 [mlx5_core] mlx5e_safe_switch_params+0x1b5/0x2e0 [mlx5_core] set_feature_lro+0x1c2/0x330 [mlx5_core] mlx5e_handle_feature+0xc8/0x140 [mlx5_core] mlx5e_set_features+0x233/0x2e0 [mlx5_core] __netdev_update_features+0x5be/0x1670 __netdev_update_features+0x71f/0x1670 dev_ethtool+0x21c5/0x4aa0 dev_ioctl+0x438/0xae0 sock_ioctl+0x2ba/0x690 __x64_sys_ioctl+0xa78/0x1700 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Fixes: 7e4d784f5810 ("net: hold netdev instance lock during rtnetlink operations") Signed-off-by: Cosmin Ratiu <cratiu(a)nvidia.com> --- net/core/dev.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 1be7cb73a602..77472364225c 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -10620,8 +10620,11 @@ int __netdev_update_features(struct net_device *dev) /* some features must be disabled on lower devices when disabled * on an upper device (think: bonding master or bridge) */ - netdev_for_each_lower_dev(dev, lower, iter) + netdev_for_each_lower_dev(dev, lower, iter) { + netdev_lock_ops(lower); netdev_sync_lower_features(dev, lower, features); + netdev_unlock_ops(lower); + } if (!err) { netdev_features_t diff = features ^ dev->features; -- 2.45.0

6 months

2
9
0 0

[PATCH bpf-next v3 0/5] Replace CONFIG_DMABUF_SYSFS_STATS with BPF

by T.J. Mercier

Until CONFIG_DMABUF_SYSFS_STATS was added [1] it was only possible to perform per-buffer accounting with debugfs which is not suitable for production environments. Eventually we discovered the overhead with per-buffer sysfs file creation/removal was significantly impacting allocation and free times, and exacerbated kernfs lock contention. [2] dma_buf_stats_setup() is responsible for 39% of single-page buffer creation duration, or 74% of single-page dma_buf_export() duration when stressing dmabuf allocations and frees. I prototyped a change from per-buffer to per-exporter statistics with a RCU protected list of exporter allocations that accommodates most (but not all) of our use-cases and avoids almost all of the sysfs overhead. While that adds less overhead than per-buffer sysfs, and less even than the maintenance of the dmabuf debugfs_list, it's still *additional* overhead on top of the debugfs_list and doesn't give us per-buffer info. This series uses the existing dmabuf debugfs_list to implement a BPF dmabuf iterator, which adds no overhead to buffer allocation/free and provides per-buffer info. The list has been moved outside of CONFIG_DEBUG_FS scope so that it is always populated. The BPF program loaded by userspace that extracts per-buffer information gets to define its own interface which avoids the lack of ABI stability with debugfs. This will allow us to replace our use of CONFIG_DMABUF_SYSFS_STATS, and the plan is to remove it from the kernel after the next longterm stable release. [1] https://lore.kernel.org/linux-media/20201210044400.1080308-1-hridya@google.… [2] https://lore.kernel.org/all/20220516171315.2400578-1-tjmercier@google.com v1: https://lore.kernel.org/all/20250414225227.3642618-1-tjmercier@google.com v1 -> v2: Make the DMA buffer list independent of CONFIG_DEBUG_FS per Christian König Add CONFIG_DMA_SHARED_BUFFER check to kernel/bpf/Makefile per kernel test robot Use BTF_ID_LIST_SINGLE instead of BTF_ID_LIST_GLOBAL_SINGLE per Song Liu Fixup comment style, mixing code/declarations, and use ASSERT_OK_FD in selftest per Song Liu Add BPF_ITER_RESCHED feature to bpf_dmabuf_reg_info per Alexei Starovoitov Add open-coded iterator and selftest per Alexei Starovoitov Add a second test buffer from the system dmabuf heap to selftests Use the BPF program we'll use in production for selftest per Alexei Starovoitov https://r.android.com/c/platform/system/bpfprogs/+/3616123/2/dmabufIter.c https://r.android.com/c/platform/system/memory/libmeminfo/+/3614259/1/libdm… v2: https://lore.kernel.org/all/20250504224149.1033867-1-tjmercier@google.com v2 -> v3: Rebase onto bpf-next/master Move get_next_dmabuf() into drivers/dma-buf/dma-buf.c, along with the new get_first_dmabuf(). This avoids having to expose the dmabuf list and mutex to the rest of the kernel, and keeps the dmabuf mutex operations near each other in the same file. (Christian König) Add Christian's RB to dma-buf: Rename debugfs symbols Drop RFC: dma-buf: Remove DMA-BUF statistics T.J. Mercier (5): dma-buf: Rename debugfs symbols bpf: Add dmabuf iterator bpf: Add open coded dmabuf iterator selftests/bpf: Add test for dmabuf_iter selftests/bpf: Add test for open coded dmabuf_iter drivers/dma-buf/dma-buf.c | 94 +++++-- include/linux/dma-buf.h | 5 +- kernel/bpf/Makefile | 3 + kernel/bpf/dmabuf_iter.c | 149 ++++++++++ kernel/bpf/helpers.c | 5 + .../testing/selftests/bpf/bpf_experimental.h | 5 + tools/testing/selftests/bpf/config | 3 + .../selftests/bpf/prog_tests/dmabuf_iter.c | 258 ++++++++++++++++++ .../testing/selftests/bpf/progs/dmabuf_iter.c | 91 ++++++ 9 files changed, 591 insertions(+), 22 deletions(-) create mode 100644 kernel/bpf/dmabuf_iter.c create mode 100644 tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c create mode 100644 tools/testing/selftests/bpf/progs/dmabuf_iter.c base-commit: 43745d11bfd9683abdf08ad7a5cc403d6a9ffd15 -- 2.49.0.1045.g170613ef41-goog

6 months

3
10
0 0

[PATCH RFC v7 0/8] Add NUMA mempolicy support for KVM guest-memfd

by Shivank Garg

KVM's guest-memfd memory backend currently lacks support for NUMA policy enforcement, causing guest memory allocations to be distributed arbitrarily across host NUMA nodes regardless of the policy specified by the VMM. This occurs because conventional userspace NUMA control mechanisms like mbind() are ineffective with guest-memfd, as the memory isn't directly mapped to userspace when allocations occur. This patch-series adds NUMA-aware memory placement for guest_memfd backed KVM guests. Based on community feedback, the approach has evolved as follows: - v1,v2: Extended the KVM_CREATE_GUEST_MEMFD IOCTL to pass mempolicy. - v3: Introduced fbind() syscall for VMM memory-placement configuration. - v4-v6: Current approach using shared_policy support and vm_ops (based on suggestions from David[1] and guest_memfd biweekly upstream calls[2][4]). - v7: Use inodes to store NUMA policy instead of file[5]. == Implementation == This series implements proper NUMA policy support for guest-memfd by: 1. Adding mempolicy-aware allocation APIs to the filemap layer. 2. Add custom inodes (via a dedicated slab-allocated inode cache, kvm_gmem_inode_info) to store NUMA policy and metadata for guest memory. 3. Implementing get/set_policy vm_ops in guest_memfd to support shared policy. With these changes, VMMs can now control guest memory placement by specifying: - Policy modes: default, bind, interleave, or preferred - Host NUMA nodes: List of target nodes for memory allocation Policies only affect future allocations and do not migrate existing memory. This matches mbind(2)'s default behavior which affects only new allocations unless overridden with MPOL_MF_MOVE/MPOL_MF_MOVE_ALL flags (Not supported for guest_memfd as it is unmovable). This series builds on the existing guest-memfd support in KVM and provides a clean integration path for NUMA-aware memory management in confidential computing environments. The work is primarily focused on supporting SEV-SNP requirements, though the benefits extend to any VMM using the guest-memfd backend that needs control over guest memory placement. == Example usage with QEMU (requires patched QEMU from [3]) == Snippet of the QEMU changes[3] needed to support this feature: /* Create and map guest-memfd region */ new_block->guest_memfd = kvm_create_guest_memfd( new_block->max_length, 0, errp); ... void *ptr_memfd = mmap(NULL, new_block->max_length, PROT_READ | PROT_WRITE, MAP_SHARED, new_block->guest_memfd, 0); ... /* Apply NUMA policy */ int ret = mbind(ptr_memfd, new_block->max_length, backend->policy, backend->host_nodes, maxnode+1, 0); ... QEMU Command to run SEV-SNP guest with interleaved memory across nodes 0 and 1 of the host: $ qemu-system-x86_64 \ -enable-kvm \ ... -machine memory-encryption=sev0,vmport=off \ -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 \ -numa node,nodeid=0,memdev=ram0,cpus=0-15 \ -object memory-backend-memfd,id=ram0,host-nodes=0-1,policy=interleave,size=1024M,share=true,prealloc=false == Experiment and Analysis == SEV-SNP enabled host, AMD Zen 3, 2 socket 2 NUMA node system NUMA for Policy Guest Node 0: policy=interleave, host-node=0-1 Test: Allocate and touch 50GB inside guest on node=0. * Generic Kernel (without NUMA supported guest-memfd): Node 0 Node 1 Total Before running Test: MemUsed 9981.60 3312.00 13293.60 After running Test: MemUsed 61451.72 3201.62 64653.34 Arbitrary allocations: all ~50GB allocated on node 0. * With NUMA supported guest-memfd: Node 0 Node 1 Total Before running Test: MemUsed 5003.88 3963.07 8966.94 After running Test: MemUsed 30607.55 29670.00 60277.55 Balanced memory distribution: Equal increase (~25GB) on both nodes. == Conclusion == Adding the NUMA-aware memory management to guest_memfd will make a lot of sense. Improving performance of memory-intensive and locality-sensitive workloads with fine-grained control over guest memory allocations, as pointed out in the analysis. Please review and provide feedback! Thanks, Shivank [1] https://lore.kernel.org/all/6fbef654-36e2-4be5-906e-2a648a845278@redhat.com [2] https://lore.kernel.org/all/6f2bfac2-d9e7-4e4a-9298-7accded16b4f@redhat.com [3] https://github.com/shivankgarg98/qemu/tree/guest_memfd_mbind_NUMA [4] https://lore.kernel.org/all/2b77e055-98ac-43a1-a7ad-9f9065d7f38f@amd.com [5] https://lore.kernel.org/all/diqzbjumm167.fsf@ackerleytng-ctop.c.googlers.com == Earlier postings and changelogs == v7 (current): - Add fixes suggested by Vlastimil and Ackerley. - Store NUMA policy in custom inode struct instead of file. v6: - https://lore.kernel.org/all/20250226082549.6034-1-shivankg@amd.com - Rebase to linux mainline - Drop RFC tag - Add selftests to ensure NUMA support for guest_memfd works correctly. v5: - https://lore.kernel.org/all/20250219101559.414878-1-shivankg@amd.com - Fix documentation and style issues. - Use EXPORT_SYMBOL_GPL - Split preparatory change in separate patch v4: - https://lore.kernel.org/all/20250210063227.41125-1-shivankg@amd.com - Dropped fbind() approach in favor of shared policy support. v3: - https://lore.kernel.org/all/20241105164549.154700-1-shivankg@amd.com - Introduce fbind() syscall and drop the IOCTL-based approach. v2: - https://lore.kernel.org/all/20240919094438.10987-1-shivankg@amd.com - Add fixes suggested by Matthew Wilcox. v1: - https://lore.kernel.org/all/20240916165743.201087-1-shivankg@amd.com - Proposed IOCTL based approach to pass NUMA mempolicy. Ackerley Tng (1): KVM: guest_memfd: Make guest mem use guest mem inodes instead of anonymous inodes Shivank Garg (6): mm/mempolicy: Export memory policy symbols security: Export security_inode_init_security_anon for KVM guest_memfd KVM: Add kvm_gmem_exit() cleanup function KVM: guest_memfd: Add slab-allocated inode cache KVM: guest_memfd: Enforce NUMA mempolicy using shared policy KVM: guest_memfd: selftests: Add tests for mmap and NUMA policy support Shivansh Dhiman (1): mm/filemap: Add mempolicy support to the filemap layer include/linux/pagemap.h | 41 +++ include/uapi/linux/magic.h | 1 + mm/filemap.c | 27 +- mm/mempolicy.c | 6 + security/security.c | 1 + .../testing/selftests/kvm/guest_memfd_test.c | 86 +++++- virt/kvm/guest_memfd.c | 261 ++++++++++++++++-- virt/kvm/kvm_main.c | 2 + virt/kvm/kvm_mm.h | 6 + 9 files changed, 402 insertions(+), 29 deletions(-) -- 2.34.1

6 months

5
20
0 0

[PATCH net-next 0/6] selftests: net: configure rp_filter in setup_ns

by Hangbin Liu

Some distributions enable rp_filter globally by default, which can interfere with various test cases. To address this, many tests explicitly disable rp_filter within their scripts. To avoid duplication and ensure consistent behavior across tests, this patch moves the rp_filter configuration into setup_ns, applied immediately after a new namespace is created. This change ensures that all namespace-based tests inherit the appropriate rp_filter settings, simplifying individual test scripts and improving maintainability. BTW, the patch 4/6 for srv6 is a bit large. Please tell me if you think I need to break this one. Hangbin Liu (6): selftests: net: disable rp_filter after namespace initialization selftests: net: remove redundant rp_filter configuration selftests: net: use setup_ns for bareudp testing selftests: net: use setup_ns for SRv6 tests and remove rp_filter configuration selftests: netfilter: remove rp_filter configuration selftests: mptcp: remove rp_filter configuration tools/testing/selftests/net/bareudp.sh | 49 ++--------- tools/testing/selftests/net/fib_rule_tests.sh | 3 - tools/testing/selftests/net/fib_tests.sh | 3 - tools/testing/selftests/net/icmp_redirect.sh | 2 - tools/testing/selftests/net/lib.sh | 2 + .../testing/selftests/net/mptcp/mptcp_lib.sh | 2 - .../selftests/net/netfilter/br_netfilter.sh | 3 - .../selftests/net/netfilter/bridge_brouter.sh | 2 - .../selftests/net/netfilter/conntrack_vrf.sh | 3 - tools/testing/selftests/net/netfilter/ipvs.sh | 6 -- .../selftests/net/netfilter/nft_fib.sh | 2 - .../selftests/net/netfilter/nft_nat_zones.sh | 2 - .../testing/selftests/net/netfilter/rpath.sh | 18 ++-- .../selftests/net/srv6_end_dt46_l3vpn_test.sh | 5 -- .../selftests/net/srv6_end_dt4_l3vpn_test.sh | 5 -- .../net/srv6_end_next_csid_l3vpn_test.sh | 77 ++++------------- .../net/srv6_end_x_next_csid_l3vpn_test.sh | 83 +++++-------------- .../net/srv6_hencap_red_l3vpn_test.sh | 74 ++++------------- .../net/srv6_hl2encap_red_l2vpn_test.sh | 77 ++++------------- 19 files changed, 87 insertions(+), 331 deletions(-) -- 2.46.0

6 months

4
10
0 0

[PATCH] kbuild: use ARCH from compile.h in unclean source tree msg

by Shuah Khan

When make finds the source tree unclean, it prints a message to run "make ARCH=x86_64 mrproper" message using the ARCH from the command line. The ARCH specified in the command line could be different from the ARCH of the existing build in the source tree. This could cause problems in regular kernel build and kunit workflows. Regular workflow: - Build x86_64 kernel $ make ARCH=x86_64 - Try building another arch kernel out of tree with O= $ make ARCH=um O=/linux/build - kbuild detects source tree is unclean *** *** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /linux/linux_srcdir *** - Clean source tree as suggested by kbuild $ make ARCH=um mrproper - Source clean appears to be clean, but it leaves behind generated header files under arch/x86 arch/x86/realmode/rm/pasyms.h A subsequent x86_64e build fails with "undefined symbol sev_es_trampoline_start referenced ..." kunit workflow runs into this issue: - Build x86_64 kernel - Run kunit tests: it tries to build for user specified ARCH or uml as default: $ ./tools/testing/kunit/kunit.py run - kbuild detects unclean source tree *** *** The source tree is not clean, please run 'make ARCH=um mrproper' *** in /linux/linux_6.15 *** - Clean source tree as suggested by kbuild $ make ARCH=um mrproper - Source clean appears to be clean, but it leaves behind generated header files under arch/x86 The problem shows when user tries to run tests on ARCH=x86_64: $ ./tools/testing/kunit/kunit.py run ARCH=x86_64 "undefined symbol sev_es_trampoline_start referenced ..." Build trips on arch/x86/realmode/rm/pasyms.h left behind by a prior x86_64 build. Problems related to partially cleaned source tree are hard to debug. Change Makefile to unclean source logic to use ARCH from compile.h UTS_MACHINE string. With this change kbuild prints: $ ./tools/testing/kunit/kunit.py run *** *** The source tree is not clean, please run 'make ARCH=x86_64 mrproper' *** in /linux/linux_6.15 *** Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 5aa9ee52a765..7ee29136b4da 100644 --- a/Makefile +++ b/Makefile @@ -674,7 +674,7 @@ ifeq ($(KBUILD_EXTMOD),) -d $(srctree)/include/config -o \ -d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \ echo >&2 "***"; \ - echo >&2 "*** The source tree is not clean, please run 'make$(if $(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; \ + echo >&2 "*** The source tree is not clean, please run 'make ARCH=$(shell grep UTS_MACHINE $(srctree)/include/generated/compile.h | cut -d '"' -f 2) mrproper'"; \ echo >&2 "*** in $(abs_srctree)";\ echo >&2 "***"; \ false; \ -- 2.47.2

6 months

4
8
0 0

[PATCH net] net: Lock netdevices during dev_shutdown

by Cosmin Ratiu

__qdisc_destroy() calls into various qdiscs .destroy() op, which in turn can call .ndo_setup_tc(), which requires the netdev instance lock. This commit extends the critical section in unregister_netdevice_many_notify() to cover dev_shutdown() (and dev_tcx_uninstall() as a side-effect) and acquires the netdev instance lock in __dev_change_net_namespace() for the other dev_shutdown() call. This should now guarantee that for all qdisc ops, the netdev instance lock is held during .ndo_setup_tc(). Fixes: a0527ee2df3f ("net: hold netdev instance lock during qdisc ndo_setup_tc") Signed-off-by: Cosmin Ratiu <cratiu(a)nvidia.com> --- net/core/dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 1be7cb73a602..92e004c354ea 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -11966,9 +11966,9 @@ void unregister_netdevice_many_notify(struct list_head *head, struct sk_buff *skb = NULL; /* Shutdown queueing discipline. */ + netdev_lock_ops(dev); dev_shutdown(dev); dev_tcx_uninstall(dev); - netdev_lock_ops(dev); dev_xdp_uninstall(dev); dev_memory_provider_uninstall(dev); netdev_unlock_ops(dev); @@ -12161,7 +12161,9 @@ int __dev_change_net_namespace(struct net_device *dev, struct net *net, synchronize_net(); /* Shutdown queueing discipline. */ + netdev_lock_ops(dev); dev_shutdown(dev); + netdev_unlock_ops(dev); /* Notify protocols, that we are about to destroy * this device. They should clean all the things. -- 2.45.0

6 months

3
2
0 0

[PATCH] clk: test: Forward-declare struct of_phandle_args in kunit/clk.h

by Richard Fitzgerald

Add a forward-declare of struct of_phandle_args to prevent the compiler warning: ../include/kunit/clk.h:29:63: warning: ‘struct of_phandle_args’ declared inside parameter list will not be visible outside of this definition or declaration struct clk_hw *(*get)(struct of_phandle_args *clkspec, void *data), Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> --- include/kunit/clk.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/kunit/clk.h b/include/kunit/clk.h index 0afae7688157..f226044cc78d 100644 --- a/include/kunit/clk.h +++ b/include/kunit/clk.h @@ -6,6 +6,7 @@ struct clk; struct clk_hw; struct device; struct device_node; +struct of_phandle_args; struct kunit; struct clk * -- 2.43.0

6 months

2
1
0 0

[PATCH v2] selftests: pid_namespace: Fix missing mount headers in pid_max.c

by Moon Hee Lee

Fix compilation errors in pid_max.c by including <sys/mount.h>, which provides definitions for mount(), umount2(), MS_PRIVATE, MS_REC, and MNT_DETACH. Without this header, the build fails with implicit declarations and undefined constants during selftest compilation. Changes since v1: - Included example build errors below for clarity Compile error: pid_max.c: In function ‘pid_max_cb’: pid_max.c:42:15: warning: implicit declaration of function ‘mount’ [-Wimplicit-function-declaration] 42 | ret = mount("", "/", NULL, MS_PRIVATE | MS_REC, 0); | ^~~~~ pid_max.c:42:36: error: ‘MS_PRIVATE’ undeclared; did you mean ‘MAP_PRIVATE’? pid_max.c:42:49: error: ‘MS_REC’ undeclared pid_max.c:48:9: warning: implicit declaration of function ‘umount2’ pid_max.c:48:26: error: ‘MNT_DETACH’ undeclared [...output trimmed for brevity...] make: *** [../lib.mk:222: /linux_mainline/tools/testing/selftests/pid_namespace/pid_max] Error 1 Signed-off-by: Moon Hee Lee <moonhee.lee.ca(a)gmail.com> --- tools/testing/selftests/pid_namespace/pid_max.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/pid_namespace/pid_max.c b/tools/testing/selftests/pid_namespace/pid_max.c index 51c414faabb0..972bedc475f1 100644 --- a/tools/testing/selftests/pid_namespace/pid_max.c +++ b/tools/testing/selftests/pid_namespace/pid_max.c @@ -11,6 +11,7 @@ #include <string.h> #include <syscall.h> #include <sys/wait.h> +#include <sys/mount.h> #include "../kselftest_harness.h" #include "../pidfd/pidfd.h" -- 2.43.0

6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror