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

[RFC v2 0/5] mm: introduce THP deferred setting

by Nico Pache

This series is a follow-up to [1], which adds mTHP support to khugepaged. mTHP khugepaged support was necessary for the global="defer" and mTHP="inherit" case (and others) to make sense. We've seen cases were customers switching from RHEL7 to RHEL8 see a significant increase in the memory footprint for the same workloads. Through our investigations we found that a large contributing factor to the increase in RSS was an increase in THP usage. For workloads like MySQL, or when using allocators like jemalloc, it is often recommended to set /transparent_hugepages/enabled=never. This is in part due to performance degradations and increased memory waste. This series introduces enabled=defer, this setting acts as a middle ground between always and madvise. If the mapping is MADV_HUGEPAGE, the page fault handler will act normally, making a hugepage if possible. If the allocation is not MADV_HUGEPAGE, then the page fault handler will default to the base size allocation. The caveat is that khugepaged can still operate on pages thats not MADV_HUGEPAGE. This allows for two things... one, applications specifically designed to use hugepages will get them, and two, applications that don't use hugepages can still benefit from them without aggressively inserting THPs at every possible chance. This curbs the memory waste, and defers the use of hugepages to khugepaged. Khugepaged can then scan the memory for eligible collapsing. Admins may want to lower max_ptes_none, if not, khugepaged may aggressively collapse single allocations into hugepages. TESTING: - Built for x86_64, aarch64, ppc64le, and s390x - selftests mm - In [1] I provided a script [2] that has multiple access patterns - lots of general use. These changes have been running in my VM for some time - redis testing. This test was my original case for the defer mode. What I was able to prove was that THP=always leads to increased max_latency cases; hence why it is recommended to disable THPs for redis servers. However with 'defer' we dont have the max_latency spikes and can still get the system to utilize THPs. I further tested this with the mTHP defer setting and found that redis (and probably other jmalloc users) can utilize THPs via defer (+mTHP defer) without a large latency penalty and some potential gains. I uploaded some mmtest results here [3] which compares: stock+thp=never stock+(m)thp=always khugepaged-mthp + defer (max_ptes_none=64) The results show that (m)THPs can cause some throughput regression in some cases, but also has gains in other cases. The mTHP+defer results have more gains and less losses over the (m)THP=always case. V2 Changes: - base changes on mTHP khugepaged support - Fix selftests parsing issue - add mTHP defer option - add mTHP defer Documentation [1] - https://lkml.org/lkml/2025/2/10/1982 [2] - https://gitlab.com/npache/khugepaged_mthp_test [3] - https://people.redhat.com/npache/mthp_khugepaged_defer/testoutput2/output.h… Nico Pache (5): mm: defer THP insertion to khugepaged mm: document transparent_hugepage=defer usage selftests: mm: add defer to thp setting parser khugepaged: add defer option to mTHP options mm: document mTHP defer setting Documentation/admin-guide/mm/transhuge.rst | 40 ++++++++++--- include/linux/huge_mm.h | 18 +++++- mm/huge_memory.c | 69 +++++++++++++++++++--- mm/khugepaged.c | 10 ++-- tools/testing/selftests/mm/thp_settings.c | 1 + tools/testing/selftests/mm/thp_settings.h | 1 + 6 files changed, 115 insertions(+), 24 deletions(-) -- 2.48.1

9 months

2
13
0 0

[PATCH] selftests/damon/damos_quota_goal: handle minimum quota that cannot be further reduced

by SeongJae Park

damos_quota_goal.py selftest see if DAMOS quota goals tuning feature increases or reduces the effective size quota for given score as expected. The tuning feature sets the minimum quota size as one byte, so if the effective size quota is already one, we cannot expect it further be reduced. However the test is not aware of the edge case, and fails since it shown no expected change of the effective quota. Handle the case by updating the failure logic for no change to see if it was the case, and simply skips to next test input. Fixes: f1c07c0a1662b ("selftests/damon: add a test for DAMOS quota goal") Cc: <stable(a)vger.kernel.org> # 6.10.x Reported-by: kernel test robot <oliver.sang(a)intel.com> Closes: https://lore.kernel.org/oe-lkp/202502171423.b28a918d-lkp@intel.com Signed-off-by: SeongJae Park <sj(a)kernel.org> --- tools/testing/selftests/damon/damos_quota_goal.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/damon/damos_quota_goal.py b/tools/testing/selftests/damon/damos_quota_goal.py index 18246f3b62f7..f76e0412b564 100755 --- a/tools/testing/selftests/damon/damos_quota_goal.py +++ b/tools/testing/selftests/damon/damos_quota_goal.py @@ -63,6 +63,9 @@ def main(): if last_effective_bytes != 0 else -1.0)) if last_effective_bytes == goal.effective_bytes: + # effective quota was already minimum that cannot be more reduced + if expect_increase is False and last_effective_bytes == 1: + continue print('efective bytes not changed: %d' % goal.effective_bytes) exit(1) base-commit: 20017459916819f8ae15ca3840e71fbf0ea8354e -- 2.39.5

9 months

1
0
0 0

[PATCH 0/2] selftests/ftrace: Fix ftracetest test cases

by Masami Hiramatsu (Google)

Here is a couple of patches to fix issues. I think mount_options.tc's one is a real bug(I'm not sure how it worked), but another one is an enhancement for (my) execution environment. Anyway, those should go through kselftests tree. Thank you, --- Masami Hiramatsu (Google) (2): selftests/ftrace: Fix to use remount when testing mount GID option selftests/ftrace: Make uprobe test more robust against binary name .../ftrace/test.d/00basic/mount_options.tc | 8 ++++---- .../ftrace/test.d/dynevent/add_remove_uprobe.tc | 4 +++- 2 files changed, 7 insertions(+), 5 deletions(-) -- Masami Hiramatsu (Google) <mhiramat(a)kernel.org>

9 months

4
5
0 0

Re: [PATCH v8 3/4] scanf: convert self-test to KUnit

by Andy Shevchenko

On Sat, Feb 15, 2025 at 02:52:22PM -0500, Tamir Duberstein wrote: > On Sat, Feb 15, 2025 at 1:51 PM kernel test robot <lkp(a)intel.com> wrote: > I am not able to reproduce these warnings with clang 19.1.7. They also > don't obviously make sense to me. Please, when reply, remove boielrplate stuff! I have just wasted a couple of minutes to understand what's going on in the message that is 2700 lines of text as the reply to the bot message which was ~700 lines. -- With Best Regards, Andy Shevchenko

9 months

2
1
0 0

[PATCH v6 0/6] ptrace: introduce PTRACE_SET_SYSCALL_INFO API

by Dmitry V. Levin

PTRACE_SET_SYSCALL_INFO is a generic ptrace API that complements PTRACE_GET_SYSCALL_INFO by letting the ptracer modify details of system calls the tracee is blocked in. This API allows ptracers to obtain and modify system call details in a straightforward and architecture-agnostic way, providing a consistent way of manipulating the system call number and arguments across architectures. As in case of PTRACE_GET_SYSCALL_INFO, PTRACE_SET_SYSCALL_INFO also does not aim to address numerous architecture-specific system call ABI peculiarities, like differences in the number of system call arguments for such system calls as pread64 and preadv. The current implementation supports changing only those bits of system call information that are used by strace system call tampering, namely, syscall number, syscall arguments, and syscall return value. Support of changing additional details returned by PTRACE_GET_SYSCALL_INFO, such as instruction pointer and stack pointer, could be added later if needed, by using struct ptrace_syscall_info.flags to specify the additional details that should be set. Currently, "flags" and "reserved" fields of struct ptrace_syscall_info must be initialized with zeroes; "arch", "instruction_pointer", and "stack_pointer" fields are currently ignored. PTRACE_SET_SYSCALL_INFO currently supports only PTRACE_SYSCALL_INFO_ENTRY, PTRACE_SYSCALL_INFO_EXIT, and PTRACE_SYSCALL_INFO_SECCOMP operations. Other operations could be added later if needed. Ideally, PTRACE_SET_SYSCALL_INFO should have been introduced along with PTRACE_GET_SYSCALL_INFO, but it didn't happen. The last straw that convinced me to implement PTRACE_SET_SYSCALL_INFO was apparent failure to provide an API of changing the first system call argument on riscv architecture [1]. ptrace(2) man page: long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); ... PTRACE_SET_SYSCALL_INFO Modify information about the system call that caused the stop. The "data" argument is a pointer to struct ptrace_syscall_info that specifies the system call information to be set. The "addr" argument should be set to sizeof(struct ptrace_syscall_info)). [1] https://lore.kernel.org/all/59505464-c84a-403d-972f-d4b2055eeaac@gmail.com/ Notes: v6: * mips: Submit mips_get_syscall_arg() o32 fix via mips tree to get it merged into v6.14-rc3 * Rebase to v6.14-rc3 * v5: https://lore.kernel.org/all/20250210113336.GA887@strace.io/ v5: * ptrace: Extend the commit message to say that the new API does not aim to address numerous architecture-specific syscall ABI peculiarities * selftests: Add a workaround for s390 16-bit syscall numbers * Add more Acked-by * v4: https://lore.kernel.org/all/20250203065849.GA14120@strace.io/ v4: * Split out syscall_set_return_value() for hexagon into a separate patch * s390: Change the style of syscall_set_arguments() implementation as requested * Add more Reviewed-by * v3: https://lore.kernel.org/all/20250128091445.GA8257@strace.io/ v3: * powerpc: Submit syscall_set_return_value() fix for "sc" case separately * mips: Do not introduce erroneous argument truncation on mips n32, add a detailed description to the commit message of the mips_get_syscall_arg() change * ptrace: Add explicit padding to the end of struct ptrace_syscall_info, simplify obtaining of user ptrace_syscall_info, do not introduce PTRACE_SYSCALL_INFO_SIZE_VER0 * ptrace: Change the return type of ptrace_set_syscall_info_* functions from "unsigned long" to "int" * ptrace: Add -ERANGE check to ptrace_set_syscall_info_exit(), add comments to -ERANGE checks * ptrace: Update comments about supported syscall stops * selftests: Extend set_syscall_info test, fix for mips n32 * Add Tested-by and Reviewed-by v2: * Add patch to fix syscall_set_return_value() on powerpc * Add patch to fix mips_get_syscall_arg() on mips * Add syscall_set_return_value() implementation on hexagon * Add syscall_set_return_value() invocation to syscall_set_nr() on arm and arm64. * Fix syscall_set_nr() and mips_set_syscall_arg() on mips * Add a comment to syscall_set_nr() on arc, powerpc, s390, sh, and sparc * Remove redundant ptrace_syscall_info.op assignments in ptrace_get_syscall_info_* * Minor style tweaks in ptrace_get_syscall_info_op() * Remove syscall_set_return_value() invocation from ptrace_set_syscall_info_entry() * Skip syscall_set_arguments() invocation in case of syscall number -1 in ptrace_set_syscall_info_entry() * Split ptrace_syscall_info.reserved into ptrace_syscall_info.reserved and ptrace_syscall_info.flags * Use __kernel_ulong_t instead of unsigned long in set_syscall_info test Dmitry V. Levin (6): hexagon: add syscall_set_return_value() syscall.h: add syscall_set_arguments() syscall.h: introduce syscall_set_nr() ptrace_get_syscall_info: factor out ptrace_get_syscall_info_op ptrace: introduce PTRACE_SET_SYSCALL_INFO request selftests/ptrace: add a test case for PTRACE_SET_SYSCALL_INFO arch/arc/include/asm/syscall.h | 25 + arch/arm/include/asm/syscall.h | 37 ++ arch/arm64/include/asm/syscall.h | 29 + arch/csky/include/asm/syscall.h | 13 + arch/hexagon/include/asm/syscall.h | 21 + arch/loongarch/include/asm/syscall.h | 15 + arch/m68k/include/asm/syscall.h | 7 + arch/microblaze/include/asm/syscall.h | 7 + arch/mips/include/asm/syscall.h | 46 ++ arch/nios2/include/asm/syscall.h | 16 + arch/openrisc/include/asm/syscall.h | 13 + arch/parisc/include/asm/syscall.h | 19 + arch/powerpc/include/asm/syscall.h | 20 + arch/riscv/include/asm/syscall.h | 16 + arch/s390/include/asm/syscall.h | 21 + arch/sh/include/asm/syscall_32.h | 24 + arch/sparc/include/asm/syscall.h | 22 + arch/um/include/asm/syscall-generic.h | 19 + arch/x86/include/asm/syscall.h | 43 ++ arch/xtensa/include/asm/syscall.h | 18 + include/asm-generic/syscall.h | 30 + include/uapi/linux/ptrace.h | 7 +- kernel/ptrace.c | 179 +++++- tools/testing/selftests/ptrace/Makefile | 2 +- .../selftests/ptrace/set_syscall_info.c | 519 ++++++++++++++++++ 25 files changed, 1141 insertions(+), 27 deletions(-) create mode 100644 tools/testing/selftests/ptrace/set_syscall_info.c base-commit: 0ad2507d5d93f39619fc42372c347d6006b64319 -- ldv

9 months

1
0
0 0

[PATCH v7 0/6] 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. For now we only adjust pidfd_get_task() and the pidfd_send_signal() system call with specific handling for this, implementing this functionality for process_madvise(), process_mrelease() (albeit, using it here wouldn't really make sense) and pidfd_send_signal(). We defer making further changes, as this would require a significant rework of the pidfd mechanism. The motivating case here is to support PIDFD_SELF in process_madvise(), so this suffices for immediate uses. Moving forward, this can be further expanded to other uses. v7: * Reworked implementation according to Christian's requirements. We now only support process_madvise() and pidfd_send_signal() system calls with PIDFD_SELF as specified. * Updated tests to account for broken pidfd_open_test.c implementation. * Fixed missing includes in pidfd self tests. * Removed tests relating to functionality no longer supported. * Update guard pages test to use PIDFD_SELF. v6: * Avoid static inline in UAPI header as suggested by Pedro. * Place PIDFD_SELF values out of range of errors and any other sentinel as suggested by Pedro. https://lore.kernel.org/linux-mm/cover.1729926229.git.lorenzo.stoakes@oracl… v5: * Fixup self test dependencies on pidfd/pidfd.h. https://lore.kernel.org/linux-mm/cover.1729848252.git.lorenzo.stoakes@oracl… v4: * Avoid returning an fd in the __pidfd_get_pid() function as pointed out by Christian, instead simply always pin the pid and maintain fd scope in the helper alone. * Add wrapper header file in tools/include/linux to allow for import of UAPI pidfd.h header without encountering the collision between system fcntl.h and linux/fcntl.h as discussed with Shuah and John. * Fixup tests to import the UAPI pidfd.h header working around conflicts between system fcntl.h and linux/fcntl.h which the UAPI pidfd.h imports, as reported by Shuah. * Use an int for pidfd_is_self_sentinel() to avoid any dependency on stdbool.h in userland. https://lore.kernel.org/linux-mm/cover.1729198898.git.lorenzo.stoakes@oracl… v3: * Do not fput() an invalid fd as reported by kernel test bot. * Fix unintended churn from moving variable declaration. https://lore.kernel.org/linux-mm/cover.1729073310.git.lorenzo.stoakes@oracl… 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 (6): pidfd: add PIDFD_SELF* sentinels to refer to own thread/process selftests/pidfd: add missing system header imcludes to pidfd tests tools: testing: separate out wait_for_pid() into helper header selftests: pidfd: add pidfd.h UAPI wrapper selftests: pidfd: add tests for PIDFD_SELF_* selftests/mm: use PIDFD_SELF in guard pages test include/uapi/linux/pidfd.h | 24 ++++ kernel/pid.c | 24 +++- kernel/signal.c | 106 +++++++++++------- tools/include/linux/pidfd.h | 14 +++ tools/testing/selftests/cgroup/test_kill.c | 2 +- tools/testing/selftests/mm/Makefile | 4 + tools/testing/selftests/mm/guard-pages.c | 15 +-- .../pid_namespace/regression_enomem.c | 2 +- tools/testing/selftests/pidfd/Makefile | 3 +- tools/testing/selftests/pidfd/pidfd.h | 28 +---- .../selftests/pidfd/pidfd_fdinfo_test.c | 1 + tools/testing/selftests/pidfd/pidfd_helpers.h | 39 +++++++ .../testing/selftests/pidfd/pidfd_open_test.c | 6 +- .../selftests/pidfd/pidfd_setns_test.c | 1 + tools/testing/selftests/pidfd/pidfd_test.c | 76 +++++++++++-- 15 files changed, 242 insertions(+), 103 deletions(-) create mode 100644 tools/include/linux/pidfd.h create mode 100644 tools/testing/selftests/pidfd/pidfd_helpers.h -- 2.48.1

9 months

8
26
0 0

[linux-next:master] [lib/prime_numbers] 313b38a6ec: kernel-selftests.lib.prime_numbers.sh.fail

by kernel test robot

Hello, kernel test robot noticed "kernel-selftests.lib.prime_numbers.sh.fail" on: commit: 313b38a6ecb46db4002925af91b64df4f2b76d1f ("lib/prime_numbers: convert self-test to KUnit") https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master [test failed on linux-next/master 0ae0fa3bf0b44c8611d114a9f69985bf451010c3] in testcase: kernel-selftests version: kernel-selftests-x86_64-78a632a2086c-1_20250215 with following parameters: group: lib config: x86_64-rhel-9.4-kselftests compiler: gcc-12 test machine: 4 threads Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (Skylake) with 16G memory (please refer to attached dmesg/kmsg for entire log/backtrace) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202502171110.708d965a-lkp@intel.com # timeout set to 300 # selftests: lib: prime_numbers.sh # Warning: file prime_numbers.sh is missing! not ok 3 selftests: lib: prime_numbers.sh (missed the change for tools/testing/selftests/lib/Makefile?) The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250217/202502171110.708d965a-lkp@… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

9 months

1
0
0 0

[PATCH v6 0/4] Migrate PCI Endpoint Subsystem tests to Kselftest

by Manivannan Sadhasivam

Hi, This series carries forward the effort to add Kselftest for PCI Endpoint Subsystem started by Aman Gupta [1] a while ago. I reworked the initial version based on another patch that fixes the return values of IOCTLs in pci_endpoint_test driver and did many cleanups. Since the resulting work modified the initial version substantially, I took over the authorship. This series also incorporates the review comment by Shuah Khan [2] to move the existing tests from 'tools/pci' to 'tools/testing/kselftest/pci_endpoint' before migrating to Kselftest framework. I made sure that the tests are executable in each commit and updated documentation accordingly. - Mani [1] https://lore.kernel.org/linux-pci/20221007053934.5188-1-aman1.gupta@samsung… [2] https://lore.kernel.org/linux-pci/b2a5db97-dc59-33ab-71cd-f591e0b1b34d@linu… Changes in v6: * Fixed the documentation to pass max MSI and MSI-X count to configfs * Collected tags Changes in v5: * Incorporated comments from Niklas * Added a patch to fix the DMA MEMCPY check in pci-epf-test driver * Collected tags * Rebased on top of pci/next 0333f56dbbf7ef6bb46d2906766c3e1b2a04a94d Changes in v4: * Dropped the BAR fix patches and submitted them separately: https://lore.kernel.org/linux-pci/20241231130224.38206-1-manivannan.sadhasi… * Rebased on top of pci/next 9e1b45d7a5bc0ad20f6b5267992da422884b916e Changes in v3: * Collected tags. * Added a note about failing testcase 10 and command to skip it in documentation. * Removed Aman Gupta and Padmanabhan Rajanbabu from CC as their addresses are bouncing. Changes in v2: * Added a patch that fixes return values of IOCTL in pci_endpoint_test driver * Moved the existing tests to new location before migrating * Added a fix for BARs on Qcom devices * Updated documentation and also added fixture variants for memcpy & DMA modes Manivannan Sadhasivam (4): PCI: endpoint: pci-epf-test: Fix the check for DMA MEMCPY test misc: pci_endpoint_test: Fix the return value of IOCTL selftests: Move PCI Endpoint tests from tools/pci to Kselftests selftests: pci_endpoint: Migrate to Kselftest framework Documentation/PCI/endpoint/pci-test-howto.rst | 174 +++++------- MAINTAINERS | 2 +- drivers/misc/pci_endpoint_test.c | 255 +++++++++-------- drivers/pci/endpoint/functions/pci-epf-test.c | 4 +- tools/pci/Build | 1 - tools/pci/Makefile | 58 ---- tools/pci/pcitest.c | 264 ------------------ tools/pci/pcitest.sh | 73 ----- tools/testing/selftests/Makefile | 1 + .../testing/selftests/pci_endpoint/.gitignore | 2 + tools/testing/selftests/pci_endpoint/Makefile | 7 + tools/testing/selftests/pci_endpoint/config | 4 + .../pci_endpoint/pci_endpoint_test.c | 221 +++++++++++++++ 13 files changed, 437 insertions(+), 629 deletions(-) delete mode 100644 tools/pci/Build delete mode 100644 tools/pci/Makefile delete mode 100644 tools/pci/pcitest.c delete mode 100644 tools/pci/pcitest.sh create mode 100644 tools/testing/selftests/pci_endpoint/.gitignore create mode 100644 tools/testing/selftests/pci_endpoint/Makefile create mode 100644 tools/testing/selftests/pci_endpoint/config create mode 100644 tools/testing/selftests/pci_endpoint/pci_endpoint_test.c -- 2.25.1

9 months

3
6
0 0

[PATCH net-next] tun: Pad virtio headers

by Akihiko Odaki

tun used to simply advance iov_iter when it needs to pad virtio header, which leaves the garbage in the buffer as is. This is especially problematic when tun starts to allow enabling the hash reporting feature; even if the feature is enabled, the packet may lack a hash value and may contain a hole in the virtio header because the packet arrived before the feature gets enabled or does not contain the header fields to be hashed. If the hole is not filled with zero, it is impossible to tell if the packet lacks a hash value. In theory, a user of tun can fill the buffer with zero before calling read() to avoid such a problem, but leaving the garbage in the buffer is awkward anyway so fill the buffer in tun. The specification also says the device MUST set num_buffers to 1 when the field is present so set it when the specified header size is big enough to contain the field. Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- drivers/net/tap.c | 2 +- drivers/net/tun.c | 6 ++++-- drivers/net/tun_vnet.h | 14 +++++++++----- 3 files changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/net/tap.c b/drivers/net/tap.c index 1287e241f4454fb8ec4975bbaded5fbaa88e3cc8..d96009153c316f669e626d95002e5fe8add3a1b2 100644 --- a/drivers/net/tap.c +++ b/drivers/net/tap.c @@ -711,7 +711,7 @@ static ssize_t tap_put_user(struct tap_queue *q, int total; if (q->flags & IFF_VNET_HDR) { - struct virtio_net_hdr vnet_hdr; + struct virtio_net_hdr_v1 vnet_hdr; vnet_hdr_len = READ_ONCE(q->vnet_hdr_sz); diff --git a/drivers/net/tun.c b/drivers/net/tun.c index b14231a743915c2851eaae49d757b763ec4a8841..a3aed7e42c63d8b8f523c0141c7d970ab185178c 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1987,7 +1987,9 @@ static ssize_t tun_put_user_xdp(struct tun_struct *tun, ssize_t ret; if (tun->flags & IFF_VNET_HDR) { - struct virtio_net_hdr gso = { 0 }; + struct virtio_net_hdr_v1 gso = { + .num_buffers = cpu_to_tun_vnet16(tun->flags, 1) + }; vnet_hdr_sz = READ_ONCE(tun->vnet_hdr_sz); ret = tun_vnet_hdr_put(vnet_hdr_sz, iter, &gso); @@ -2040,7 +2042,7 @@ static ssize_t tun_put_user(struct tun_struct *tun, } if (vnet_hdr_sz) { - struct virtio_net_hdr gso; + struct virtio_net_hdr_v1 gso; ret = tun_vnet_hdr_from_skb(tun->flags, tun->dev, skb, &gso); if (ret) diff --git a/drivers/net/tun_vnet.h b/drivers/net/tun_vnet.h index fd7411c4447ffb180e032fe3e22f6709c30da8e9..b4f406f522728f92266898969831c26a87930f6a 100644 --- a/drivers/net/tun_vnet.h +++ b/drivers/net/tun_vnet.h @@ -135,15 +135,17 @@ static inline int tun_vnet_hdr_get(int sz, unsigned int flags, } static inline int tun_vnet_hdr_put(int sz, struct iov_iter *iter, - const struct virtio_net_hdr *hdr) + const struct virtio_net_hdr_v1 *hdr) { + int content_sz = MIN(sizeof(*hdr), sz); + if (unlikely(iov_iter_count(iter) < sz)) return -EINVAL; - if (unlikely(copy_to_iter(hdr, sizeof(*hdr), iter) != sizeof(*hdr))) + if (unlikely(copy_to_iter(hdr, content_sz, iter) != content_sz)) return -EFAULT; - iov_iter_advance(iter, sz - sizeof(*hdr)); + iov_iter_zero(sz - content_sz, iter); return 0; } @@ -157,11 +159,11 @@ static inline int tun_vnet_hdr_to_skb(unsigned int flags, struct sk_buff *skb, static inline int tun_vnet_hdr_from_skb(unsigned int flags, const struct net_device *dev, const struct sk_buff *skb, - struct virtio_net_hdr *hdr) + struct virtio_net_hdr_v1 *hdr) { int vlan_hlen = skb_vlan_tag_present(skb) ? VLAN_HLEN : 0; - if (virtio_net_hdr_from_skb(skb, hdr, + if (virtio_net_hdr_from_skb(skb, (struct virtio_net_hdr *)hdr, tun_vnet_is_little_endian(flags), true, vlan_hlen)) { struct skb_shared_info *sinfo = skb_shinfo(skb); @@ -179,6 +181,8 @@ static inline int tun_vnet_hdr_from_skb(unsigned int flags, return -EINVAL; } + hdr->num_buffers = cpu_to_tun_vnet16(flags, 1); + return 0; } --- base-commit: f54eab84fc17ef79b701e29364b7d08ca3a1d2f6 change-id: 20250116-buffers-96e14bf023fc prerequisite-change-id: 20241230-tun-66e10a49b0c7:v6 prerequisite-patch-id: 871dc5f146fb6b0e3ec8612971a8e8190472c0fb prerequisite-patch-id: 2797ed249d32590321f088373d4055ff3f430a0e prerequisite-patch-id: ea3370c72d4904e2f0536ec76ba5d26784c0cede prerequisite-patch-id: 837e4cf5d6b451424f9b1639455e83a260c4440d prerequisite-patch-id: ea701076f57819e844f5a35efe5cbc5712d3080d prerequisite-patch-id: 701646fb43ad04cc64dd2bf13c150ccbe6f828ce prerequisite-patch-id: 53176dae0c003f5b6c114d43f936cf7140d31bb5 Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

9 months

3
5
0 0

[PATCH net-next] selftest:net: fixed spelling mistakes

by Andres Urian Florez

Fixed spelling errors in test_redirect6() error message and test_port_shadowing() comments Signed-off-by: Andres Urian Florez <andres.emb.sys(a)gmail.com> --- tools/testing/selftests/net/netfilter/nft_nat.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/net/netfilter/nft_nat.sh b/tools/testing/selftests/net/netfilter/nft_nat.sh index 9e39de26455f..8143b877ae7d 100755 --- a/tools/testing/selftests/net/netfilter/nft_nat.sh +++ b/tools/testing/selftests/net/netfilter/nft_nat.sh @@ -569,7 +569,7 @@ test_redirect6() ip netns exec "$ns0" sysctl net.ipv6.conf.all.forwarding=1 > /dev/null if ! ip netns exec "$ns2" ping -q -c 1 dead:1::99 > /dev/null;then - echo "ERROR: cannnot ping $ns1 from $ns2 via ipv6" + echo "ERROR: cannot ping $ns1 from $ns2 via ipv6" lret=1 fi @@ -859,7 +859,7 @@ EOF # from router:service bypass connection tracking. test_port_shadow_notrack "$family" - # test nat based mitigation: fowarded packets coming from service port + # test nat based mitigation: forwarded packets coming from service port # are masqueraded with random highport. test_port_shadow_pat "$family" -- 2.43.0

9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror