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

[PATCH AUTOSEL 5.9 11/15] selftests/bpf: Fix array access with signed variable test

by Sasha Levin

From: Jean-Philippe Brucker <jean-philippe(a)linaro.org> [ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ] The test fails because of a recent fix to the verifier, even though this program is valid. In details what happens is: 7: (61) r1 = *(u32 *)(r0 +0) Load a 32-bit value, with signed bounds [S32_MIN, S32_MAX]. The bounds of the 64-bit value are [0, U32_MAX]... 8: (65) if r1 s> 0xffffffff goto pc+1 ... therefore this is always true (the operand is sign-extended). 10: (b4) w2 = 11 11: (6d) if r2 s> r1 goto pc+1 When true, the 64-bit bounds become [0, 10]. The 32-bit bounds are still [S32_MIN, 10]. 13: (64) w1 <<= 2 Because this is a 32-bit operation, the verifier propagates the new 32-bit bounds to the 64-bit ones, and the knowledge gained from insn 11 is lost. 14: (0f) r0 += r1 15: (7a) *(u64 *)(r0 +0) = 4 Then the verifier considers r0 unbounded here, rejecting the test. To make the test work, change insn 8 to check the sign of the 32-bit value. Signed-off-by: Jean-Philippe Brucker <jean-philippe(a)linaro.org> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/bpf/verifier/array_access.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/verifier/array_access.c b/tools/testing/selftests/bpf/verifier/array_access.c index 1c4b1939f5a8d..bed53b561e044 100644 --- a/tools/testing/selftests/bpf/verifier/array_access.c +++ b/tools/testing/selftests/bpf/verifier/array_access.c @@ -68,7 +68,7 @@ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 9), BPF_LDX_MEM(BPF_W, BPF_REG_1, BPF_REG_0, 0), - BPF_JMP_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1), + BPF_JMP32_IMM(BPF_JSGT, BPF_REG_1, 0xffffffff, 1), BPF_MOV32_IMM(BPF_REG_1, 0), BPF_MOV32_IMM(BPF_REG_2, MAX_ENTRIES), BPF_JMP_REG(BPF_JSGT, BPF_REG_2, BPF_REG_1, 1), -- 2.27.0

4 years, 8 months

1
0
0 0

Re: kernel BUG at drivers/dma-buf/dma-buf.c:LINE!

by syzbot

syzbot suspects this issue was fixed by commit: commit e722a295cf493388dae474745d30e91e1a2ec549 Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu Aug 27 12:36:27 2020 +0000 staging: ion: remove from the tree bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17d4f137500000 start commit: abb3438d Merge tag 'm68knommu-for-v5.9-rc3' of git://git.k.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994 dashboard link: https://syzkaller.appspot.com/bug?extid=d6734079f30f7fc39021 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17428596900000 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: staging: ion: remove from the tree For information about bisection process see: https://goo.gl/tpsmEJ#bisection

4 years, 8 months

2
1
0 0

[PATCH][next] selftests/bpf: fix spelling mistake "tranmission" -> "transmission"

by Colin King

From: Colin Ian King <colin.king(a)canonical.com> There are two spelling mistakes in output messages. Fix these. Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- tools/testing/selftests/bpf/xdpxceiver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf/xdpxceiver.c b/tools/testing/selftests/bpf/xdpxceiver.c index 014dedaa4dd2..1e722ee76b1f 100644 --- a/tools/testing/selftests/bpf/xdpxceiver.c +++ b/tools/testing/selftests/bpf/xdpxceiver.c @@ -715,7 +715,7 @@ static void worker_pkt_dump(void) int payload = *((uint32_t *)(pkt_buf[iter]->payload + PKT_HDR_SIZE)); if (payload == EOT) { - ksft_print_msg("End-of-tranmission frame received\n"); + ksft_print_msg("End-of-transmission frame received\n"); fprintf(stdout, "---------------------------------------\n"); break; } @@ -747,7 +747,7 @@ static void worker_pkt_validate(void) } if (payloadseqnum == EOT) { - ksft_print_msg("End-of-tranmission frame received: PASS\n"); + ksft_print_msg("End-of-transmission frame received: PASS\n"); sigvar = 1; break; } -- 2.29.2

4 years, 8 months

2
1
0 0

[RFC PATCH 6/8] selftests/x86: Test Key Locker internal key maintenance

by Chang S. Bae

The test validates the internal key to be the same in all CPUs. It performs the validation again with the Suspend-To-RAM (ACPI S3) state. Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Cc: linux-kernel(a)vger.kernel.org Cc: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/keylocker.c | 177 ++++++++++++++++++++++++ 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/x86/keylocker.c diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 6703c7906b71..c53e496d77b2 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -13,7 +13,7 @@ CAN_BUILD_WITH_NOPIE := $(shell ./check_cc.sh $(CC) trivial_program.c -no-pie) TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt test_mremap_vdso \ check_initial_reg_state sigreturn iopl ioperm \ test_vdso test_vsyscall mov_ss_trap \ - syscall_arg_fault fsgsbase_restore + syscall_arg_fault fsgsbase_restore keylocker TARGETS_C_32BIT_ONLY := entry_from_vm86 test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ vdso_restorer diff --git a/tools/testing/selftests/x86/keylocker.c b/tools/testing/selftests/x86/keylocker.c new file mode 100644 index 000000000000..3d69c1615bca --- /dev/null +++ b/tools/testing/selftests/x86/keylocker.c @@ -0,0 +1,177 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * keylocker.c, validating the internal key management + */ +#undef _GNU_SOURCE +#define _GNU_SOURCE 1 + +#include <stdio.h> +#include <stdbool.h> +#include <string.h> +#include <fcntl.h> +#include <err.h> +#include <sched.h> +#include <setjmp.h> +#include <signal.h> +#include <unistd.h> + +#define HANDLE_SIZE 48 + +static bool keylocker_disabled; + +/* Encode a 128-bit key to a 384-bit handle */ +static inline void __encode_key(char *handle) +{ + static const unsigned char aeskey[] = { 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, + 0x71, 0x77, 0x74, 0x69, 0x6f, 0x6b, 0x6c, 0x78 }; + + asm volatile ("movdqu %0, %%xmm0" : : "m" (*aeskey) :); + + /* Set no restriction to the handle */ + asm volatile ("mov $0, %%eax" :); + + /* ENCODEKEY128 %EAX */ + asm volatile (".byte 0xf3, 0xf, 0x38, 0xfa, 0xc0"); + + asm volatile ("movdqu %%xmm0, %0; movdqu %%xmm1, %1; movdqu %%xmm2, %2;" + : "=m" (handle[0]), "=m" (handle[0x10]), "=m" (handle[0x20])); +} + +static jmp_buf jmpbuf; + +static void handle_sigill(int sig, siginfo_t *si, void *ctx_void) +{ + keylocker_disabled = true; + siglongjmp(jmpbuf, 1); +} + +static bool encode_key(char *handle) +{ + bool success = true; + struct sigaction sa; + int ret; + + memset(&sa, 0, sizeof(sa)); + + /* Set signal handler */ + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = handle_sigill; + sigemptyset(&sa.sa_mask); + ret = sigaction(SIGILL, &sa, 0); + if (ret) + err(1, "sigaction"); + + if (sigsetjmp(jmpbuf, 1)) + success = false; + else + __encode_key(handle); + + /* Clear signal handler */ + sa.sa_flags = 0; + sa.sa_sigaction = NULL; + sa.sa_handler = SIG_DFL; + sigemptyset(&sa.sa_mask); + ret = sigaction(SIGILL, &sa, 0); + if (ret) + err(1, "sigaction"); + + return success; +} + +/* + * Test if the internal key is the same in all the CPUs: + * + * Since the value is not readable, compare the encoded output of a AES key + * between CPUs. + */ + +static int nerrs; + +static unsigned char cpu0_handle[HANDLE_SIZE] = { 0 }; + +static void test_internal_key(bool slept, long cpus) +{ + int cpu, errs; + + printf("Test the internal key consistency between CPUs\n"); + + for (cpu = 0, errs = 0; cpu < cpus; cpu++) { + char handle[HANDLE_SIZE] = { 0 }; + cpu_set_t mask; + bool success; + + CPU_ZERO(&mask); + CPU_SET(cpu, &mask); + sched_setaffinity(0, sizeof(cpu_set_t), &mask); + + success = encode_key(handle); + if (!success) { + /* The encode should success after the S3 sleep */ + if (slept) + errs++; + printf("[%s]\tKey Locker disabled at CPU%d\n", + slept ? "FAIL" : "NOTE", cpu); + continue; + } + + if (cpu == 0 && !slept) { + /* Record the first handle value as reference */ + memcpy(cpu0_handle, handle, HANDLE_SIZE); + } else if (memcmp(cpu0_handle, handle, HANDLE_SIZE)) { + printf("[FAIL]\tMismatched internal key at CPU%d\n", + cpu); + errs++; + } + } + + if (errs == 0 && !keylocker_disabled) + printf("[OK]\tAll the internal keys are the same\n"); + else + nerrs += errs; +} + +static void switch_to_sleep(bool *slept) +{ + ssize_t bytes; + int fd; + + printf("Transition to Suspend-To-RAM state\n"); + + fd = open("/sys/power/mem_sleep", O_RDWR); + if (fd < 0) + err(1, "Open /sys/power/mem_sleep"); + + bytes = write(fd, "deep", strlen("deep")); + if (bytes != strlen("deep")) + err(1, "Write /sys/power/mem_sleep"); + close(fd); + + fd = open("/sys/power/state", O_RDWR); + if (fd < 0) + err(1, "Open /sys/power/state"); + + bytes = write(fd, "mem", strlen("mem")); + if (bytes != strlen("mem")) + err(1, "Write /sys/power/state"); + close(fd); + + printf("Wake up from Suspend-To-RAM state\n"); + *slept = true; +} + +int main(void) +{ + bool slept = false; + long cpus; + + cpus = sysconf(_SC_NPROCESSORS_ONLN); + printf("%ld CPUs in the system\n", cpus); + + test_internal_key(slept, cpus); + if (keylocker_disabled) + return nerrs ? 1 : 0; + + switch_to_sleep(&slept); + test_internal_key(slept, cpus); + return nerrs ? 1 : 0; +} -- 2.17.1

4 years, 8 months

3
2
0 0

[PATCH] selftests: Skip BPF seftests by default

by Mark Brown

The BPF selftests have build time dependencies on cutting edge versions of tools in the BPF ecosystem including LLVM which are more involved to satisfy than more typical requirements like installing a package from your distribution. This causes issues for users looking at kselftest in as a whole who find that a default build of kselftest fails and that resolving this is time consuming and adds administrative overhead. The fast pace of BPF development and the need for a full BPF stack to do substantial development or validation work on the code mean that people working directly on it don't see a reasonable way to keep supporting older environments without causing problems with the usability of the BPF tests in BPF development so these requirements are unlikely to be relaxed in the immediate future. There is already support for skipping targets so in order to reduce the barrier to entry for people interested in kselftest as a whole let's use that to skip the BPF tests by default when people work with the top level kselftest build system. Users can still build the BPF selftests as part of the wider kselftest build by specifying SKIP_TARGETS, including setting an empty SKIP_TARGETS to build everything. They can also continue to build the BPF selftests individually in cases where they are specifically focused on BPF. This isn't ideal since it means people will need to take special steps to build the BPF tests but the dependencies mean that realistically this is already the case to some extent and it makes it easier for people to pick up and work with the other selftests which is hopefully a net win. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile index afbab4aeef3c..8a917cb4426a 100644 --- a/tools/testing/selftests/Makefile +++ b/tools/testing/selftests/Makefile @@ -77,8 +77,10 @@ TARGETS += zram TARGETS_HOTPLUG = cpu-hotplug TARGETS_HOTPLUG += memory-hotplug -# User can optionally provide a TARGETS skiplist. -SKIP_TARGETS ?= +# User can optionally provide a TARGETS skiplist. By default we skip +# BPF since it has cutting edge build time dependencies which require +# more effort to install. +SKIP_TARGETS ?= bpf ifneq ($(SKIP_TARGETS),) TMP := $(filter-out $(SKIP_TARGETS), $(TARGETS)) override TARGETS := $(TMP) -- 2.20.1

4 years, 9 months

4
7
0 0

[PATCH] selftests/vDSO: fix -Wformat warning in vdso_test_correctness

by Tobias Klauser

Fix the following -Wformat warnings in vdso_test_correctness.c: vdso_test_correctness.c: In function ‘test_one_clock_gettime64’: vdso_test_correctness.c:352:21: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=] 352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n", | ~~~~^ | | | long int | %09lld 353 | (unsigned long long)start.tv_sec, start.tv_nsec, | ~~~~~~~~~~~~~ | | | long long int vdso_test_correctness.c:352:32: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘long long int’ [-Wformat=] 352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n", | ~~~~^ | | | long int | %09lld 353 | (unsigned long long)start.tv_sec, start.tv_nsec, 354 | (unsigned long long)vdso.tv_sec, vdso.tv_nsec, | ~~~~~~~~~~~~ | | | long long int vdso_test_correctness.c:352:43: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 7 has type ‘long long int’ [-Wformat=] The tv_sec member of __kernel_timespec is long long, both in uapi/linux/time_types.h and locally in vdso_test_correctness.c. Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch> --- tools/testing/selftests/vDSO/vdso_test_correctness.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/vDSO/vdso_test_correctness.c b/tools/testing/selftests/vDSO/vdso_test_correctness.c index 5029ef9b228c..c4aea794725a 100644 --- a/tools/testing/selftests/vDSO/vdso_test_correctness.c +++ b/tools/testing/selftests/vDSO/vdso_test_correctness.c @@ -349,7 +349,7 @@ static void test_one_clock_gettime64(int clock, const char *name) return; } - printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n", + printf("\t%llu.%09lld %llu.%09lld %llu.%09lld\n", (unsigned long long)start.tv_sec, start.tv_nsec, (unsigned long long)vdso.tv_sec, vdso.tv_nsec, (unsigned long long)end.tv_sec, end.tv_nsec); -- 2.29.0

4 years, 9 months

2
1
0 0

[PATCH] selftests/vDSO: add additional binaries to .gitignore

by Tobias Klauser

Add the test binaries introduced by commit 693f5ca08ca0 ("kselftest: Extend vDSO selftest"), commit 03f55c7952c9 ("kselftest: Extend vDSO selftest to clock_getres") and commit c7e5789b24d3 ("kselftest: Move test_vdso to the vDSO test suite") to .gitignore. Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch> --- tools/testing/selftests/vDSO/.gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/vDSO/.gitignore b/tools/testing/selftests/vDSO/.gitignore index 5eb64d41e541..a8dc51af5a9c 100644 --- a/tools/testing/selftests/vDSO/.gitignore +++ b/tools/testing/selftests/vDSO/.gitignore @@ -1,5 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only vdso_test +vdso_test_abi +vdso_test_clock_getres +vdso_test_correctness vdso_test_gettimeofday vdso_test_getcpu vdso_standalone_test_x86 -- 2.29.0

4 years, 9 months

2
1
0 0

[PATCH v4 0/5] Speed up mremap on large regions

by Kalesh Singh

This is a repost of the mremap speed up patches, adding Kirill's Acked-by's (from a separate discussion). The previous versions are posted at: v1 - https://lore.kernel.org/r/20200930222130.4175584-1-kaleshsingh@google.com v2 - https://lore.kernel.org/r/20201002162101.665549-1-kaleshsingh@google.com v3 - http://lore.kernel.org/r/20201005154017.474722-1-kaleshsingh@google.com mremap time can be optimized by moving entries at the PMD/PUD level if the source and destination addresses are PMD/PUD-aligned and PMD/PUD-sized. Enable moving at the PMD and PUD levels on arm64 and x86. Other architectures where this type of move is supported and known to be safe can also opt-in to these optimizations by enabling HAVE_MOVE_PMD and HAVE_MOVE_PUD. Observed Performance Improvements for remapping a PUD-aligned 1GB-sized region on x86 and arm64: - HAVE_MOVE_PMD is already enabled on x86 : N/A - Enabling HAVE_MOVE_PUD on x86 : ~13x speed up - Enabling HAVE_MOVE_PMD on arm64 : ~ 8x speed up - Enabling HAVE_MOVE_PUD on arm64 : ~19x speed up Altogether, HAVE_MOVE_PMD and HAVE_MOVE_PUD give a total of ~150x speed up on arm64. Changes in v2: - Reduce mremap_test time by only validating a configurable threshold of the remapped region, as per John. - Use a random pattern for mremap validation. Provide pattern seed in test output, as per John. - Moved set_pud_at() to separate patch, per Kirill. - Use switch() instead of ifs in move_pgt_entry(), per Kirill. - Update commit message with description of Android garbage collector use case for HAVE_MOVE_PUD, as per Joel. - Fix build test error reported by kernel test robot in [1]. Changes in v3: - Make lines 80 cols or less where they don’t need to be longer, per John. - Removed unused PATTERN_SIZE in mremap_test - Added Reviewed-by tag for patch 1/5 (mremap kselftest patch). - Use switch() instead of ifs in get_extent(), per Kirill - Add BUILD_BUG() is get_extent() default case. - Move get_old_pud() and alloc_new_pud() out of #ifdef CONFIG_HAVE_MOVE_PUD, per Kirill. - Have get_old_pmd() and alloc_new_pmd() use get_old_pud() and alloc_old_pud(), per Kirill. - Replace #ifdef CONFIG_HAVE_MOVE_PMD / PUD in move_page_tables() with IS_ENABLED(CONFIG_HAVE_MOVE_PMD / PUD), per Kirill. - Fold Add set_pud_at() patch into patch 4/5, per Kirill. [1] https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/CKPGL4F… Kalesh Singh (5): kselftests: vm: Add mremap tests arm64: mremap speedup - Enable HAVE_MOVE_PMD mm: Speedup mremap on 1GB or larger regions arm64: mremap speedup - Enable HAVE_MOVE_PUD x86: mremap speedup - Enable HAVE_MOVE_PUD arch/Kconfig | 7 + arch/arm64/Kconfig | 2 + arch/arm64/include/asm/pgtable.h | 1 + arch/x86/Kconfig | 1 + mm/mremap.c | 230 ++++++++++++--- tools/testing/selftests/vm/.gitignore | 1 + tools/testing/selftests/vm/Makefile | 1 + tools/testing/selftests/vm/mremap_test.c | 344 +++++++++++++++++++++++ tools/testing/selftests/vm/run_vmtests | 11 + 9 files changed, 558 insertions(+), 40 deletions(-) create mode 100644 tools/testing/selftests/vm/mremap_test.c -- 2.28.0.1011.ga647a8990f-goog

4 years, 9 months

4
11
0 0

[PATCH 1/2] selftest: don't offline the last CPU in cpu hotplug test

by Lai Jiangshan

From: Lai Jiangshan <laijs(a)linux.alibaba.com> In my box, all CPUs are allowed to be offline. The test tries to offline all offline-able CPUs and causes fail on the last one. We should just skip offlining the last CPU Signed-off-by: Lai Jiangshan <laijs(a)linux.alibaba.com> --- tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh b/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh index 0d26b5e3f966..5cdef96326a7 100755 --- a/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh +++ b/tools/testing/selftests/cpu-hotplug/cpu-on-off-test.sh @@ -126,6 +126,11 @@ offline_cpu_expect_success() { local cpu=$1 + # don't offline the last CPU if all CPUs are offline-able + if [[ a$cpu = a`cat $SYSFS/devices/system/cpu/online` ]]; then + return + fi + if ! offline_cpu $cpu; then echo $FUNCNAME $cpu: unexpected fail >&2 exit 1 -- 2.19.1.6.gb485710b

4 years, 9 months

1
1
0 0

Re: [dm-devel] [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace

by Palmer Dabbelt

On Tue, 15 Dec 2020 22:17:06 PST (-0800), ruby.wktk(a)gmail.com wrote: > Hi my name is Akira Hayakawa. I am maintaining an out-of-tree DM target > named dm-writeboost. > > Sorry to step in. But this is a very interesting topic at least to me. > > I have been looking for something like dm-user because I believe we should > be able to implement virtual block devices in Rust language. > > I know proxying IO requests to userland always causes some overhead but for > some type of device that performance doesn't matter or some research > prototyping or pseudo device for testing, this way should be developed. Of > course, implementation in Rust will give us opportunities to develop more > complicated software in high quality. > > I noticed this thread few days ago then I started to prototype this library > https://github.com/akiradeveloper/userland-io > > It is what I want but the transport is still NBD which I don't like so > much. If dm-user is available, I will implement a transport using dm-user. Great, I'm glad to hear that. Obviously this is still in the early days and we're talking about high-level ABI design here, so things are almost certainly going to change, but it's always good to have people pushing on stuff. Just be warned: we've only had two people write userspaces for this (one of which was me, and all that is test code) so I'd be shocked if you manage to avoid running into bugs. > > - Akira > > On Tue, Dec 15, 2020 at 7:00 PM Palmer Dabbelt <palmer(a)dabbelt.com> wrote: > >> On Thu, 10 Dec 2020 09:03:21 PST (-0800), josef(a)toxicpanda.com wrote: >> > On 12/9/20 10:38 PM, Bart Van Assche wrote: >> >> On 12/7/20 10:55 AM, Palmer Dabbelt wrote: >> >>> All in all, I've found it a bit hard to figure out what sort of >> interest >> >>> people >> >>> have in dm-user: when I bring this up I seem to run into people who've >> done >> >>> similar things before and are vaguely interested, but certainly nobody >> is >> >>> chomping at the bit. I'm sending it out in this early state to try and >> >>> figure >> >>> out if it's interesting enough to keep going. >> >> >> >> Cc-ing Josef and Mike since their nbd contributions make me wonder >> >> whether this new driver could be useful to their use cases? >> >> >> > >> > Sorry gmail+imap sucks and I can't get my email client to get at the >> original >> > thread. However here is my take. >> >> and I guess I then have to apoligize for missing your email ;). Hopefully >> that >> was the problem, but who knows. >> >> > 1) The advantages of using dm-user of NBD that you listed aren't actually >> > problems for NBD. We have NBD working in production where you can hand >> off the >> > sockets for the server without ending in timeouts, it was actually the >> main >> > reason we wrote our own server so we could use the FD transfer stuff to >> restart >> > the server without impacting any clients that had the device in use. >> >> OK. So you just send the FD around using one of the standard mechanisms to >> orchestrate the handoff? I guess that might work for our use case, >> assuming >> whatever the security side of things was doing was OK with the old FD. >> TBH I'm >> not sure how all that works and while we thought about doing that sort of >> transfer scheme we decided to just open it again -- not sure how far we >> were >> down the dm-user rabbit hole at that point, though, as this sort of arose >> out >> of some other ideas. >> >> > 2) The extra copy is a big deal, in fact we already have too many copies >> in our >> > existing NBD setup and are actively looking for ways to avoid those. >> > >> > Don't take this as I don't think dm-user is a good idea, but I think at >> the very >> > least it should start with the very best we have to offer, starting with >> as few >> > copies as possible. >> >> I was really experting someone to say that. It does seem kind of silly to >> build >> out the new interface, but not go all the way to a ring buffer. We just >> didn't >> really have any way to justify the extra complexity as our use cases aren't >> that high performance. I kind of like to have benchmarks for this sort of >> thing, though, and I didn't have anyone who had bothered avoiding the last >> copy >> to compare against. >> >> > If you are using it currently in production then cool, there's clearly a >> usecase >> > for it. Personally as I get older and grouchier I want less things in >> the >> > kernel, so if this enables us to eventually do everything NBD related in >> > userspace with no performance drop then I'd be down. I don't think you >> need to >> > make that your primary goal, but at least polishing this up so it could >> > potentially be abused in the future would make it more compelling for >> merging. >> > Thanks, >> >> Ya, it's in Android already and we'll be shipping it as part of the new OTA >> flow for the next release. The rules on deprecation are a bit different >> over >> there, though, so it's not like we're wed to it. The whole point of >> bringing >> this up here was to try and get something usable by everyone, and while I'd >> eventually like to get whatever's in Android into the kernel proper we'd >> really >> planned on supporting an extra Android-only ABI for a cycle at least. >> >> I'm kind of inclined to take a crack at the extra copy, to at least see if >> building something that eliminates it is viable. I'm not really sure if >> it is >> (or at least, if it'll net us a meaningful amount of performance), but >> it'd at >> least be interesting to try. >> >> It'd be nice to have some benchmark target, though, as otherwise this stuff >> hangs on forever. My workloads are in selftests later on in the patch >> set, but >> I'm essentially using tmpfs as a baseline to compare against ext4+dm-user >> with >> some FIO examples as workloads. Our early benchmark numbers indicated >> this was >> way faster than we needed, so I didn't even bother putting together a >> proper >> system to run on so I don't really have any meaningful numbers there. Is >> there >> an NBD server that's fast that I should be comparing against? >> >> I haven't gotten a whole lot of feedback, so I'm inclined to at least have >> some >> reasonable performance numbers before bothering with a v2. >> >> -- >> dm-devel mailing list >> dm-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/dm-devel

4 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror