September 2023 - Linux-kselftest-mirror

[PATCH v2 0/4] kunit: Fix some bugs in kunit

by Jinjie Ruan

The test_cases is not freed in kunit_free_suite_set(). And the copy pointer may be moved in kunit_filter_suites(). The filtered_suite and filtered_suite->test_cases allocated in the last kunit_filter_attr_tests() in last inner for loop may be leaked if kunit_filter_suites() fails. If kunit_filter_suites() succeeds, not only copy but also filtered_suite and filtered_suite->test_cases should be freed. Changes in v2: - Add Reviewed-by. - Add the memory leak backtrace for the 4th patch. - Remove the unused func kernel test robot noticed for the 4th patch. - Update the commit message for the 4th patch. Jinjie Ruan (4): kunit: Fix missed memory release in kunit_free_suite_set() kunit: Fix the wrong kfree of copy for kunit_filter_suites() kunit: Fix possible memory leak in kunit_filter_suites() kunit: test: Fix the possible memory leak in executor_test lib/kunit/executor.c | 23 ++++++++++++++++------ lib/kunit/executor_test.c | 40 ++++++++++++++++++--------------------- 2 files changed, 35 insertions(+), 28 deletions(-) -- 2.34.1

2 years

4
11
0 0

Re: [PATCH] list: test: potential dereference of null pointer

by David Gow

On Thu, 21 Sept 2023 at 16:18, Ma Ke <make_ruc2021(a)163.com> wrote: > > To avoid the failure of alloc, we could check the return value of > kmalloc() and kzalloc(). > > Signed-off-by: Ma Ke <make_ruc2021(a)163.com> > --- Fair enough, though I'd want the test to fail in this case (or, at the very least, be skipped). Could we use KUNIT_ASSERT_NOT_NULL() here? Furthermore, there are a few bugs in the patch, see below. Cheers, -- David > lib/list-test.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/lib/list-test.c b/lib/list-test.c > index 0cc27de9cec8..9f82cac3a822 100644 > --- a/lib/list-test.c > +++ b/lib/list-test.c > @@ -27,9 +27,14 @@ static void list_test_list_init(struct kunit *test) > INIT_LIST_HEAD(&list2); > > list4 = kzalloc(sizeof(*list4), GFP_KERNEL | __GFP_NOFAIL); > + if (!list4) > + return; Instead, let's use: KUNIT_ASSERT_NOT_NULL(test, list4) > INIT_LIST_HEAD(list4); > > list5 = kmalloc(sizeof(*list5), GFP_KERNEL | __GFP_NOFAIL); > + if (!list5) Shouldn't this be in {}s? We don't want to return unconditionally. > + kfree(list5); We shouldn't free a NULL pointer. Should this be kfree(list4)? Either way, maybe we should swap the allocations out for kunit_kzalloc(), which will automatically free everything on test exit. > + return; Again, let's use KUNIT_ASSERT_NOT_NULL() here. Or at the very least, call KUNIT_FAIL() to make sure we're noting the test has failed. > memset(list5, 0xFF, sizeof(*list5)); > INIT_LIST_HEAD(list5); > > -- > 2.37.2 >

2 years

1
0
0 0

[PATCH 0/3] userfaultfd remap option

by Suren Baghdasaryan

This patch series introduces UFFDIO_REMAP feature to userfaultfd, which has long been implemented and maintained by Andrea in his local tree [1], but was not upstreamed due to lack of use cases where this approach would be better than allocating a new page and copying the contents. UFFDIO_COPY performs ~20% better than UFFDIO_REMAP when the application needs pages to be allocated [2]. However, with UFFDIO_REMAP, if pages are available (in userspace) for recycling, as is usually the case in heap compaction algorithms, then we can avoid the page allocation and memcpy (done by UFFDIO_COPY). Also, since the pages are recycled in the userspace, we avoid the need to release (via madvise) the pages back to the kernel [3]. We see over 40% reduction (on a Google pixel 6 device) in the compacting thread’s completion time by using UFFDIO_REMAP vs. UFFDIO_COPY. This was measured using a benchmark that emulates a heap compaction implementation using userfaultfd (to allow concurrent accesses by application threads). More details of the usecase are explained in [3]. Furthermore, UFFDIO_REMAP enables remapping swapped-out pages without touching them within the same vma. Today, it can only be done by mremap, however it forces splitting the vma. Main changes since Andrea's last version [1]: 1. Trivial translations from page to folio, mmap_sem to mmap_lock 2. Replace pmd_trans_unstable() with pte_offset_map_nolock() and handle its possible failure 3. Move pte mapping into remap_pages_pte to allow for retries when source page or anon_vma is contended. Since pte_offset_map_nolock() start RCU read section, we can't block anymore after mapping a pte, so have to unmap the ptesm do the locking and retry. 4. Add and use anon_vma_trylock_write() to avoid blocking while in RCU read section. 5. Accommodate changes in mmu_notifier_range_init() API, switch to mmu_notifier_invalidate_range_start_nonblock() to avoid blocking while in RCU read section. 6. Open-code now removed __swp_swapcount() 7. Replace pmd_read_atomic() with pmdp_get_lockless() 8. Add new selftest for UFFDIO_REMAP [1] https://gitlab.com/aarcange/aa/-/commit/2aec7aea56b10438a3881a20a411aa4b1fc… [2] https://lore.kernel.org/all/1425575884-2574-1-git-send-email-aarcange@redha… [3] https://lore.kernel.org/linux-mm/CA+EESO4uO84SSnBhArH4HvLNhaUQ5nZKNKXqxRCyj… Andrea Arcangeli (2): userfaultfd: UFFDIO_REMAP: rmap preparation userfaultfd: UFFDIO_REMAP uABI Suren Baghdasaryan (1): selftests/mm: add UFFDIO_REMAP ioctl test fs/userfaultfd.c | 49 ++ include/linux/rmap.h | 5 + include/linux/userfaultfd_k.h | 17 + include/uapi/linux/userfaultfd.h | 22 + mm/huge_memory.c | 118 ++++ mm/khugepaged.c | 3 + mm/rmap.c | 13 + mm/userfaultfd.c | 586 +++++++++++++++++++ tools/testing/selftests/mm/uffd-common.c | 34 +- tools/testing/selftests/mm/uffd-common.h | 1 + tools/testing/selftests/mm/uffd-unit-tests.c | 62 ++ 11 files changed, 908 insertions(+), 2 deletions(-) -- 2.42.0.283.g2d96d420d3-goog

2 years

5
27
0 0

[RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion

by Nícolas F. R. A. Prado

Add a configuration file for the mt8192-asurada-spherion platform to validate that the card and PCMs used for speaker, headphone and microphones (internal and headset) are correctly exposed to userspace. Signed-off-by: Nícolas F. R. A. Prado <nfraprado(a)collabora.com> --- Sending this patch as RFC because I'd like to ask a question. What would be the most suitable entry to identify the card in a future-proof way? I have used the card ID here, but given that it is generated at runtime with the purpose of being unique among the cards present on the system (and I couldn't find any documentation that states it is stable), I'm not sure it is supposed to be relied on. The card ID is derived from the driver name or card longname, which are themselves stable given userspace (alsa-ucm-conf) relies on them, but those aren't exposed through sysfs so I can't check for them here. Another option would be to look for the card number 0. But in the (very unlikely) case that another soundcard would be connected to the platform and detected first during boot, it wouldn't work. Yet another option would be to look at the device's uevent file for the compatible as defined in the Devicetree, ie path "device/uevent" regex "OF_COMPATIBLE_.*=mediatek,mt8192_mt6359_rt1015p_rt5682" Though it is possible (in rare circumstances) for the compatible in the Devicetree to need to be updated to enable a driver behavior that isn't backward compatible. I realize most of these issues are very rare and probably won't ever occur, but it seems worthwhile to use the most future-proof mechanism available to identify the card to avoid unnecessary maintenance, even more so considering the example would be followed by future configurations. Thanks, Nícolas .../alsa/conf.d/mt8192-asurada-spherion.conf | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf diff --git a/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf new file mode 100644 index 000000000000..6a7e15dc17da --- /dev/null +++ b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf @@ -0,0 +1,32 @@ +sysfs [ + { + path "firmware/devicetree/base/compatible" + regex "google,spherion" + } +] + +card.mt8192 { + sysfs [ + { + path "id" + regex "mt8192mt6359rt1" + } + ] + + pcm.0.0 { + PLAYBACK { + } + } + pcm.3.0 { + PLAYBACK { + } + } + pcm.10.0 { + CAPTURE { + } + } + pcm.11.0 { + CAPTURE { + } + } +} -- 2.42.0

2 years

1
0
0 0

[PATCH v4 0/8] add UFFDIO_POISON to simulate memory poisoning with UFFD

by Axel Rasmussen

This series adds a new userfaultfd feature, UFFDIO_POISON. See commit 4 for a detailed description of the feature. The series is based on Linus master (partial 6.5 merge window), and structured like this: - Patches 1-3 are preparation / refactoring - Patches 4-6 implement and advertise the new feature - Patches 7-8 implement a unit test for the new feature Changelog: v3 -> v4: - [Peter] Rename PTE_MARKER_ERROR and helpers to PTE_MARKER_POISONED. - [Peter] Switch from calloc to memset for initializing some state in the selftest. v2 -> v3: - Rebase onto current Linus master. - Don't overwrite existing PTE markers for non-hugetlb UFFDIO_POISON. Before, non-hugetlb would override them, but hugetlb would not. I don't think there's a use case where we *want* to override a UFFD_WP marker for example, so take the more conservative behavior for all kinds of memory. - [Peter] Drop hugetlb mfill atomic refactoring, since it isn't needed for this series (we don't touch that code directly anyway). - [Peter] Switch to re-using PTE_MARKER_SWAPIN_ERROR instead of defining new PTE_MARKER_UFFD_POISON. - [Peter] Extract start / len range overflow check into existing validate_range helper; this fixes the style issue of unnecessary braces in the UFFDIO_POISON implementation, because this code is just deleted. - [Peter] Extract file size check out into a new helper. - [Peter] Defer actually "enabling" the new feature until the last commit in the series; combine this with adding the documentation. As a consequence, move the selftest commits after this one. - [Randy] Fix typo in documentation. v1 -> v2: - [Peter] Return VM_FAULT_HWPOISON not VM_FAULT_SIGBUS, to yield the correct behavior for KVM (guest MCE). - [Peter] Rename UFFDIO_SIGBUS to UFFDIO_POISON. - [Peter] Implement hugetlbfs support for UFFDIO_POISON. Axel Rasmussen (8): mm: make PTE_MARKER_SWAPIN_ERROR more general mm: userfaultfd: check for start + len overflow in validate_range mm: userfaultfd: extract file size check out into a helper mm: userfaultfd: add new UFFDIO_POISON ioctl mm: userfaultfd: support UFFDIO_POISON for hugetlbfs mm: userfaultfd: document and enable new UFFDIO_POISON feature selftests/mm: refactor uffd_poll_thread to allow custom fault handlers selftests/mm: add uffd unit test for UFFDIO_POISON Documentation/admin-guide/mm/userfaultfd.rst | 15 +++ fs/userfaultfd.c | 73 ++++++++++-- include/linux/mm_inline.h | 19 +++ include/linux/swapops.h | 15 ++- include/linux/userfaultfd_k.h | 4 + include/uapi/linux/userfaultfd.h | 25 +++- mm/hugetlb.c | 51 ++++++-- mm/madvise.c | 2 +- mm/memory.c | 15 ++- mm/mprotect.c | 4 +- mm/shmem.c | 4 +- mm/swapfile.c | 2 +- mm/userfaultfd.c | 83 ++++++++++--- tools/testing/selftests/mm/uffd-common.c | 5 +- tools/testing/selftests/mm/uffd-common.h | 3 + tools/testing/selftests/mm/uffd-stress.c | 8 +- tools/testing/selftests/mm/uffd-unit-tests.c | 117 +++++++++++++++++++ 17 files changed, 379 insertions(+), 66 deletions(-) -- 2.41.0.255.g8b1d071c50-goog

2 years, 1 month

4
15
0 0

selftests: user_events: ftrace_test: Internal error: Oops: 0000000096000021

by Naresh Kamboju

Following selftests: user_events: ftrace_test running on arm64 Juno-r2 Linux next-20230919. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> kselftest: Running tests in user_events TAP version 13 1..4 # timeout set to 90 # selftests: user_events: ftrace_test [ 1138.755735] Unable to handle kernel paging request at virtual address ffff00082fc89ed4 [ 1138.763768] Mem abort info: [ 1138.766692] ESR = 0x0000000096000021 [ 1138.770495] EC = 0x25: DABT (current EL), IL = 32 bits [ 1138.775879] SET = 0, FnV = 0 [ 1138.779018] EA = 0, S1PTW = 0 [ 1138.782264] FSC = 0x21: alignment fault [ 1138.786399] Data abort info: [ 1138.789356] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 1138.794969] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1138.800095] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1138.805436] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000008265b000 [ 1138.812175] [ffff00082fc89ed4] pgd=18000009ffdf8003, p4d=18000009ffdf8003, pud=18000009ffa0e003, pmd=18000009ff88f003, pte=00680008afc89707 [ 1138.824824] Internal error: Oops: 0000000096000021 [#1] PREEMPT SMP # TAP[ 1138.831117] Modules linked in: tda998x hdlcd onboard_usb_hub crct10dif_ce cec drm_dma_helper drm_kms_helper drm fuse backlight dm_mod ip_tables x_tables [ 1138.845227] CPU: 1 PID: 4752 Comm: ftrace_test Not tainted 6.6.0-rc2-next-20230919 #1 v[e r1s1i3o8n. 81533080] Hardware name: ARM Juno development board (r2) (DT) # 1..6 # # Starting 6 tests from 1 test cases. # # RUN user.register_events ... [ 1138.868317] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1138.875291] pc : user_event_enabler_write (arch/arm64/include/asm/atomic_ll_sc.h:210 (discriminator 2) arch/arm64/include/asm/atomic.h:64 (discriminator 2) include/linux/atomic/atomic-arch-fallback.h:3656 (discriminator 2) include/linux/atomic/atomic-long.h:964 (discriminator 2) include/asm-generic/bitops/atomic.h:25 (discriminator 2) include/asm-generic/bitops/instrumented-atomic.h:42 (discriminator 2) kernel/trace/trace_events_user.c:520 (discriminator 2)) [ 1138.880362] lr : user_event_enabler_write (kernel/trace/trace_events_user.c:503 (discriminator 1)) [ 1138.885337] sp : ffff80008a593b70 [ 1138.888656] x29: ffff80008a593b70 x28: ffff000800908040 x27: ffff00082767ac40 [ 1138.895817] x26: 0000000000000000 x25: ffff000827732600 x24: 0000ffffc2a46ca0 [ 1138.902972] x23: 0000000000000000 x22: ffff000822773a00 x21: 0000000000000ed4 [ 1138.910128] x20: ffff80008a593c40 x19: ffff00082767ac40 x18: 0000000000000000 [ 1138.917283] x17: ffff8000816f1aa0 x16: ffff80008002ce90 x15: ffff800081cea0b8 [ 1138.924439] x14: ffffffffffffffff x13: 0000ffffadc52000 x12: 1fffe001048d5b21 [ 1138.931597] x11: ffff0008246ad900 x10: ffff0008246ad908 x9 : ffff80008003bc40 [ 1138.938752] x8 : ffff80008a5937d8 x7 : 0000000000000000 x6 : 0000000000000001 [ 1138.945905] x5 : 0000000000000001 x4 : fffffc0020bf2240 x3 : 000000000000001f [ 1138.953058] x2 : 0000000000000000 x1 : 0000000080000000 x0 : ffff00082fc89ed4 [ 1138.960212] Call trace: [ 1138.962656] user_event_enabler_write (arch/arm64/include/asm/atomic_ll_sc.h:210 (discriminator 2) arch/arm64/include/asm/atomic.h:64 (discriminator 2) include/linux/atomic/atomic-arch-fallback.h:3656 (discriminator 2) include/linux/atomic/atomic-long.h:964 (discriminator 2) include/asm-generic/bitops/atomic.h:25 (discriminator 2) include/asm-generic/bitops/instrumented-atomic.h:42 (discriminator 2) kernel/trace/trace_events_user.c:520 (discriminator 2)) [ 1138.967372] user_events_ioctl (kernel/trace/trace_events_user.c:858 kernel/trace/trace_events_user.c:2314 kernel/trace/trace_events_user.c:2475) [ 1138.971477] __arm64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:871 fs/ioctl.c:857 fs/ioctl.c:857) [ 1138.975497] invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:56) [ 1138.979255] el0_svc_common.constprop.0 (include/linux/thread_info.h:127 (discriminator 2) arch/arm64/kernel/syscall.c:144 (discriminator 2)) [ 1138.984056] do_el0_svc (arch/arm64/kernel/syscall.c:156) [ 1138.987377] el0_svc (arch/arm64/include/asm/daifflags.h:28 arch/arm64/kernel/entry-common.c:133 arch/arm64/kernel/entry-common.c:144 arch/arm64/kernel/entry-common.c:679) [ 1138.990439] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:697) [ 1138.994805] el0t_64_sync (arch/arm64/kernel/entry.S:591) [ 1138.998474] Code: 14000009 f821301f 17ffffed f9800011 (c85f7c02) All code ======== 0:* 09 00 or %eax,(%rax) <-- trapping instruction 2: 00 14 1f add %dl,(%rdi,%rbx,1) 5: 30 21 xor %ah,(%rcx) 7: f8 clc 8: ed in (%dx),%eax 9: ff (bad) a: ff 17 callq *(%rdi) c: 11 00 adc %eax,(%rax) e: 80 f9 02 cmp $0x2,%cl 11: 7c 5f jl 0x72 13: c8 .byte 0xc8 Code starting with the faulting instruction =========================================== 0: 02 7c 5f c8 add -0x38(%rdi,%rbx,2),%bh [ 1139.004575] ---[ end trace 0000000000000000 ]--- # # register_events: Test terminated by timeout # # FAIL user.register_events # not ok 1 user.register_events # # RUN user.write_events ... # # write_events: Test terminated by timeout # # FAIL user.write_events # not ok 2 user.write_events # # RUN user.write_empty_events ... Log: - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230919/te… - https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230919/te… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2VbYWmjbGM16bFDtcoFx… -- Linaro LKFT https://lkft.linaro.org

2 years, 1 month

3
3
0 0

[PATCH V7 0/7] amd-pstate preferred core

by Meng Li

Hi all: The core frequency is subjected to the process variation in semiconductors. Not all cores are able to reach the maximum frequency respecting the infrastructure limits. Consequently, AMD has redefined the concept of maximum frequency of a part. This means that a fraction of cores can reach maximum frequency. To find the best process scheduling policy for a given scenario, OS needs to know the core ordering informed by the platform through highest performance capability register of the CPPC interface. Earlier implementations of amd-pstate preferred core only support a static core ranking and targeted performance. Now it has the ability to dynamically change the preferred core based on the workload and platform conditions and accounting for thermals and aging. Amd-pstate driver utilizes the functions and data structures provided by the ITMT architecture to enable the scheduler to favor scheduling on cores which can be get a higher frequency with lower voltage. We call it amd-pstate preferred core. Here sched_set_itmt_core_prio() is called to set priorities and sched_set_itmt_support() is called to enable ITMT feature. Amd-pstate driver uses the highest performance value to indicate the priority of CPU. The higher value has a higher priority. Amd-pstate driver will provide an initial core ordering at boot time. It relies on the CPPC interface to communicate the core ranking to the operating system and scheduler to make sure that OS is choosing the cores with highest performance firstly for scheduling the process. When amd-pstate driver receives a message with the highest performance change, it will update the core ranking. Changes form V6->V7: - x86: - - Modify kconfig about X86_AMD_PSTATE. - cpufreq: amd-pstate: - - modify incorrect comments about scheduler_work(). - - convert highest_perf data type. - - modify preferred core init when cpu init and online. - acpi: cppc: - - modify link of CPPC highest performance. - cpufreq: - - modify link of CPPC highest performance changed. Changes form V5->V6: - cpufreq: amd-pstate: - - modify the wrong tag order. - - modify warning about hw_prefcore sysfs attribute. - - delete duplicate comments. - - modify the variable name cppc_highest_perf to prefcore_ranking. - - modify judgment conditions for setting highest_perf. - - modify sysfs attribute for CPPC highest perf to pr_debug message. - Documentation: amd-pstate: - - modify warning: title underline too short. Changes form V4->V5: - cpufreq: amd-pstate: - - modify sysfs attribute for CPPC highest perf. - - modify warning about comments - - rebase linux-next - cpufreq: - - Moidfy warning about function declarations. - Documentation: amd-pstate: - - align with ``amd-pstat`` Changes form V3->V4: - Documentation: amd-pstate: - - Modify inappropriate descriptions. Changes form V2->V3: - x86: - - Modify kconfig and description. - cpufreq: amd-pstate: - - Add Co-developed-by tag in commit message. - cpufreq: - - Modify commit message. - Documentation: amd-pstate: - - Modify inappropriate descriptions. Changes form V1->V2: - acpi: cppc: - - Add reference link. - cpufreq: - - Moidfy link error. - cpufreq: amd-pstate: - - Init the priorities of all online CPUs - - Use a single variable to represent the status of preferred core. - Documentation: - - Default enabled preferred core. - Documentation: amd-pstate: - - Modify inappropriate descriptions. - - Default enabled preferred core. - - Use a single variable to represent the status of preferred core. Meng Li (7): x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion. acpi: cppc: Add get the highest performance cppc control cpufreq: amd-pstate: Enable amd-pstate preferred core supporting. cpufreq: Add a notification message that the highest perf has changed cpufreq: amd-pstate: Update amd-pstate preferred core ranking dynamically Documentation: amd-pstate: introduce amd-pstate preferred core Documentation: introduce amd-pstate preferrd core mode kernel command line options .../admin-guide/kernel-parameters.txt | 5 + Documentation/admin-guide/pm/amd-pstate.rst | 58 +++++- arch/x86/Kconfig | 5 +- drivers/acpi/cppc_acpi.c | 13 ++ drivers/acpi/processor_driver.c | 6 + drivers/cpufreq/amd-pstate.c | 197 ++++++++++++++++-- drivers/cpufreq/cpufreq.c | 13 ++ include/acpi/cppc_acpi.h | 5 + include/linux/amd-pstate.h | 6 + include/linux/cpufreq.h | 5 + 10 files changed, 291 insertions(+), 22 deletions(-) -- 2.34.1

2 years, 1 month

7
18
0 0

[PATCH v2 0/4] KVM RISC-V fixes for ONE_REG interface

by Anup Patel

This series includes few assorted fixes for KVM RISC-V ONE_REG interface and KVM_GET_REG_LIST API. These patches can also be found in riscv_kvm_onereg_fixes_v2 branch at: https://github.com/avpatel/linux.git Changes since v1: - Addressed Drew's comments in PATCH4 Anup Patel (4): RISC-V: KVM: Fix KVM_GET_REG_LIST API for ISA_EXT registers RISC-V: KVM: Fix riscv_vcpu_get_isa_ext_single() for missing extensions KVM: riscv: selftests: Fix ISA_EXT register handling in get-reg-list KVM: riscv: selftests: Selectively filter-out AIA registers arch/riscv/kvm/vcpu_onereg.c | 7 ++- .../selftests/kvm/riscv/get-reg-list.c | 58 ++++++++++++++----- 2 files changed, 47 insertions(+), 18 deletions(-) -- 2.34.1

2 years, 1 month

2
6
0 0

[PATCH 0/4] KVM RISC-V fixes for ONE_REG interface

by Anup Patel

This series includes few assorted fixes for KVM RISC-V ONE_REG interface and KVM_GET_REG_LIST API. These patches can also be found in riscv_kvm_onereg_fixes_v1 branch at: https://github.com/avpatel/linux.git Anup Patel (4): RISC-V: KVM: Fix KVM_GET_REG_LIST API for ISA_EXT registers RISC-V: KVM: Fix riscv_vcpu_get_isa_ext_single() for missing extensions KVM: riscv: selftests: Fix ISA_EXT register handling in get-reg-list KVM: riscv: selftests: Selectively filter-out AIA registers arch/riscv/kvm/vcpu_onereg.c | 7 ++- .../selftests/kvm/riscv/get-reg-list.c | 58 ++++++++++++++----- 2 files changed, 47 insertions(+), 18 deletions(-) -- 2.34.1

2 years, 1 month

3
20
0 0

[RFC PATCH v2 0/9] iov_iter: kunit: Cleanup, abstraction and more tests

by David Howells

Hi Jens, Can you consider taking this through the block tree? These patches make some changes to the kunit tests previously added for iov_iter testing, in particular adding testing of UBUF/IOVEC iterators and some benchmarking: (1) Clean up a couple of checkpatch style complaints. (2) Consolidate some repeated bits of code into helper functions and use the same struct to represent straight offset/address ranges and partial page lists. (3) Add a function to set up a userspace VM, attach the VM to the kunit testing thread, create an anonymous file, stuff some pages into the file and map the file into the VM to act as a buffer that can be used with UBUF/IOVEC iterators. I map an anonymous file with pages attached rather than using MAP_ANON so that I can check the pages obtained from iov_iter_extract_pages() without worrying about them changing due to swap, migrate, etc.. [?] Is this the best way to do things? Mirroring execve, it requires a number of extra core symbols to be exported. Should this be done in the core code? (4) Add tests for copying into and out of UBUF and IOVEC iterators. (5) Add tests for extracting pages from UBUF and IOVEC iterators. (6) Add tests to benchmark copying 256MiB to UBUF, IOVEC, KVEC, BVEC and XARRAY iterators. (7) Add a test to benchmark copying 256MiB through dynamically allocated 256-page bvecs to simulate bio construction. Example benchmarks output: iov_kunit_benchmark_ubuf: avg 4474 uS, stddev 1340 uS iov_kunit_benchmark_iovec: avg 6619 uS, stddev 23 uS iov_kunit_benchmark_kvec: avg 2672 uS, stddev 14 uS iov_kunit_benchmark_bvec: avg 3189 uS, stddev 19 uS iov_kunit_benchmark_bvec_split: avg 3403 uS, stddev 8 uS iov_kunit_benchmark_xarray: avg 3709 uS, stddev 7 uS I've pushed the patches here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?… David Changes ======= ver #2) - Use MAP_ANON to make the user buffer if we don't want a list of pages. - KUNIT_ASSERT_NOT_ERR_OR_NULL() doesn't like __user pointers as the condition, so cast. - Make the UBUF benchmark loop, doing an iterator per page so that the overhead from the iterator code is not negligible. - Make the KVEC benchmark use an iovec per page so that the iteration is not not negligible. - Switch the benchmarking to use copy_from_iter() so that only a single page is needed in the userspace buffer (as it can be shared R/O), not 256MiB's worth. Link: https://lore.kernel.org/r/20230914221526.3153402-1-dhowells@redhat.com/ # v1 David Howells (9): iov_iter: Fix some checkpatch complaints in kunit tests iov_iter: Consolidate some of the repeated code into helpers iov_iter: Consolidate the test vector struct in the kunit tests iov_iter: Consolidate bvec pattern checking iov_iter: Create a function to prepare userspace VM for UBUF/IOVEC tests iov_iter: Add copy kunit tests for ITER_UBUF and ITER_IOVEC iov_iter: Add extract kunit tests for ITER_UBUF and ITER_IOVEC iov_iter: Add benchmarking kunit tests iov_iter: Add benchmarking kunit tests for UBUF/IOVEC arch/loongarch/include/asm/page.h | 1 + arch/s390/kernel/vdso.c | 1 + fs/anon_inodes.c | 1 + kernel/fork.c | 2 + lib/kunit_iov_iter.c | 1241 ++++++++++++++++++++++++----- mm/mmap.c | 1 + mm/util.c | 3 + 7 files changed, 1058 insertions(+), 192 deletions(-)

2 years, 1 month

1
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror September 2023