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

kselftest/fixes build: 5 builds: 0 failed, 5 passed, 1 warning (linux_kselftest-fixes-6.10-rc3-4-ged3994ac847e)

by kernelci.org bot

kselftest/fixes build: 5 builds: 0 failed, 5 passed, 1 warning (linux_kselftest-fixes-6.10-rc3-4-ged3994ac847e) Full Build Summary: https://kernelci.org/build/kselftest/branch/fixes/kernel/linux_kselftest-fi… Tree: kselftest Branch: fixes Git Describe: linux_kselftest-fixes-6.10-rc3-4-ged3994ac847e Git Commit: ed3994ac847e0d6605f248e7f6776b1d4f445f4b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 3 unique architectures Warnings Detected: arm64: i386: x86_64: x86_64_defconfig+kselftest (clang-16): 1 warning Warnings summary: 1 vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cf94 ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, clang-16) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cf94 --- For more info write to <info(a)kernelci.org>

7 months, 1 week

1
0
0 0

[PATCH net-next v6 0/2] Add F_SETFL for fcntl in test_sockmap

by Geliang Tang

From: Geliang Tang <tanggeliang(a)kylinos.cn> v6: - add a fix for tls_sw_recvmsg(). v5: - add a new patch "Check recv lengths in test_sockmap" instead of using "continue" in msg_loop. v4: - address Martin's comments for v3. (thanks.) - add Yonghong's "Acked-by" tags. (thanks.) - update subject-prefix from "bpf-next" to "bpf". Patch 1, v3 of "selftests/bpf: Add F_SETFL for fcntl": - detect nonblock flag automatically, then test_sockmap can run in both block and nonblock modes. - use continue instead of again in v2. Patch 2, fix for umount cgroup2 error. Geliang Tang (2): tls: wait for receiving next skb for sk_redirect selftests/bpf: Add F_SETFL for fcntl in test_sockmap net/tls/tls_sw.c | 2 ++ tools/testing/selftests/bpf/test_sockmap.c | 4 +++- 2 files changed, 5 insertions(+), 1 deletion(-) -- 2.43.0

7 months, 1 week

2
3
0 0

kselftest/next build: 5 builds: 0 failed, 5 passed, 1 warning (v6.10-rc1-2-g64f5bc57b24e)

by kernelci.org bot

kselftest/next build: 5 builds: 0 failed, 5 passed, 1 warning (v6.10-rc1-2-g64f5bc57b24e) Full Build Summary: https://kernelci.org/build/kselftest/branch/next/kernel/v6.10-rc1-2-g64f5bc… Tree: kselftest Branch: next Git Describe: v6.10-rc1-2-g64f5bc57b24e Git Commit: 64f5bc57b24e8c7935d51732571d405acfcf4b99 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 4 unique architectures Warnings Detected: arm64: arm: i386: x86_64: x86_64_defconfig+kselftest (clang-16): 1 warning Warnings summary: 1 vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cf94 ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- multi_v7_defconfig+kselftest (arm, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-10) — PASS, 0 errors, 0 warnings, 0 section mismatches -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, clang-16) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cf94 --- For more info write to <info(a)kernelci.org>

7 months, 1 week

1
0
0 0

[PATCH v2] KVM: selftest: Add a common check to identify AMD cpu in perf event filter test

by Manali Shukla

PMU event filter test fails on zen4 architecture because of the unavailability of family and model check for zen4 in use_amd_pmu(). use_amd_pmu() is added to detect architectures that supports event select 0xc2 umask 0 as "retired branch instructions". Model ranges in is_zen1(), is_zen2() and is_zen3() are used only for sever SOCs, so they might not cover all the model ranges which supports retired branch instructions. X86_FEATURE_ZEN is a synthetic feature flag specifically added to recognize all Zen generations by commit 232afb557835d ("x86/CPU/AMD: Add X86_FEATURE_ZEN1"). init_amd_zen_common() uses family >= 0x17 check to enable X86_FEATURE_ZEN. Family 17h+ is where Zen and its successors start and that event 0xc2,0 is supported on all currently released F17h+ processors as branch instruction retired and it is true going forward to maintain the backward compatibility for the branch instruction retired. Since X86_FEATURE_ZEN is not recognized in selftest framework, instead of checking family and model value for all zen architecture, "family >= 0x17" check is added in use_amd_pmu(). Fixes: bef9a701f3eb ("selftests: kvm/x86: Add test for KVM_SET_PMU_EVENT_FILTER") Suggested-by: Sandipan Das <sandipan.das(a)amd.com> Signed-off-by: Manali Shukla <manali.shukla(a)amd.com> --- .../kvm/x86_64/pmu_event_filter_test.c | 32 +++---------------- 1 file changed, 5 insertions(+), 27 deletions(-) diff --git a/tools/testing/selftests/kvm/x86_64/pmu_event_filter_test.c b/tools/testing/selftests/kvm/x86_64/pmu_event_filter_test.c index 26b3e7efe5dd..f65033fab0c0 100644 --- a/tools/testing/selftests/kvm/x86_64/pmu_event_filter_test.c +++ b/tools/testing/selftests/kvm/x86_64/pmu_event_filter_test.c @@ -353,38 +353,16 @@ static bool use_intel_pmu(void) kvm_pmu_has(X86_PMU_FEATURE_BRANCH_INSNS_RETIRED); } -static bool is_zen1(uint32_t family, uint32_t model) -{ - return family == 0x17 && model <= 0x0f; -} - -static bool is_zen2(uint32_t family, uint32_t model) -{ - return family == 0x17 && model >= 0x30 && model <= 0x3f; -} - -static bool is_zen3(uint32_t family, uint32_t model) -{ - return family == 0x19 && model <= 0x0f; -} - /* - * Determining AMD support for a PMU event requires consulting the AMD - * PPR for the CPU or reference material derived therefrom. The AMD - * test code herein has been verified to work on Zen1, Zen2, and Zen3. - * - * Feel free to add more AMD CPUs that are documented to support event - * select 0xc2 umask 0 as "retired branch instructions." + * Family 17h+ is where Zen and its successors start and that event + * 0xc2,0 is supported on all currently released F17h+ processors as + * branch instruction retired and it is true going forward to maintain + * the backward compatibility for the branch instruction retired. */ static bool use_amd_pmu(void) { uint32_t family = kvm_cpu_family(); - uint32_t model = kvm_cpu_model(); - - return host_cpu_is_amd && - (is_zen1(family, model) || - is_zen2(family, model) || - is_zen3(family, model)); + return family >= 0x17; } /* -- 2.34.1

7 months, 1 week

2
2
0 0

[PATCH v3 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)chromium.org> When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it didn't have proper documentation. This led to a lot of confusion, especially about whether or not memfd created with the MFD_NOEXEC_SEAL flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set MFD_ALLOW_SEALING to be sealable, so it's a fair question. As one might have noticed, unlike other flags in memfd_create, MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea is to make it easier to use memfd in the most common way, which is NOEXEC + F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl vm.noexec to help existing applications move to a more secure way of using memfd. Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless MFD_ALLOW_SEALING is set, to be consistent with other flags [1] [2], Those are based on the viewpoint that each flag is an atomic unit, which is a reasonable assumption. However, MFD_NOEXEC_SEAL was designed with the intent of promoting the most secure method of using memfd, therefore a combination of multiple functionalities into one bit. Furthermore, the MFD_NOEXEC_SEAL has been added for more than one year, and multiple applications and distributions have backported and utilized it. Altering ABI now presents a degree of risk and may lead to disruption. MFD_NOEXEC_SEAL is a new flag, and applications must change their code to use it. There is no backward compatibility problem. When sysctl vm.noexec == 1 or 2, applications that don't set MFD_NOEXEC_SEAL or MFD_EXEC will get MFD_NOEXEC_SEAL memfd. And old-application might break, that is by-design, in such a system vm.noexec = 0 shall be used. Also no backward compatibility problem. I propose to include this documentation patch to assist in clarifying the semantics of MFD_NOEXEC_SEAL, thereby preventing any potential future confusion. This patch supersede previous patch which is trying different direction [3], and please remove [2] from mm-unstable branch when applying this patch. Finally, I would like to express my gratitude to David Rheinsberg and Barnabás Pőcze for initiating the discussion on the topic of sealability. [1] https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ [2] https://lore.kernel.org/lkml/20240513191544.94754-1-pobrn@protonmail.com/ [3] https://lore.kernel.org/lkml/20240524033933.135049-1-jeffxu@google.com/ v3: Additional Randy Dunlap' comments. v2: Update according to Randy Dunlap' comments. https://lore.kernel.org/linux-mm/20240611034903.3456796-1-jeffxu@chromium.o… v1: https://lore.kernel.org/linux-mm/20240607203543.2151433-1-jeffxu@google.com/ Jeff Xu (1): mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/mfd_noexec.rst | 86 ++++++++++++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 Documentation/userspace-api/mfd_noexec.rst -- 2.45.2.505.gda0bf45e8d-goog

7 months, 1 week

1
1
0 0

[PATCH v2 0/1] mm/memfd: add documentation for MFD_NOEXEC_SEAL

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)chromium.org> When MFD_NOEXEC_SEAL was introduced, there was one big mistake: it didn't have proper documentation. This led to a lot of confusion, especially about whether or not memfd created with the MFD_NOEXEC_SEAL flag is sealable. Before MFD_NOEXEC_SEAL, memfd had to explicitly set MFD_ALLOW_SEALING to be sealable, so it's a fair question. As one might have noticed, unlike other flags in memfd_create, MFD_NOEXEC_SEAL is actually a combination of multiple flags. The idea is to make it easier to use memfd in the most common way, which is NOEXEC + F_SEAL_EXEC + MFD_ALLOW_SEALING. This works with sysctl vm.noexec to help existing applications move to a more secure way of using memfd. Proposals have been made to put MFD_NOEXEC_SEAL non-sealable, unless MFD_ALLOW_SEALING is set, to be consistent with other flags [1] [2], Those are based on the viewpoint that each flag is an atomic unit, which is a reasonable assumption. However, MFD_NOEXEC_SEAL was designed with the intent of promoting the most secure method of using memfd, therefore a combination of multiple functionalities into one bit. Furthermore, the MFD_NOEXEC_SEAL has been added for more than one year, and multiple applications and distributions have backported and utilized it. Altering ABI now presents a degree of risk and may lead to disruption. MFD_NOEXEC_SEAL is a new flag, and applications must change their code to use it. There is no backward compatibility problem. When sysctl vm.noexec == 1 or 2, applications that don't set MFD_NOEXEC_SEAL or MFD_EXEC will get MFD_NOEXEC_SEAL memfd. And old-application might break, that is by-design, in such a system vm.noexec = 0 shall be used. Also no backward compatibility problem. I propose to include this documentation patch to assist in clarifying the semantics of MFD_NOEXEC_SEAL, thereby preventing any potential future confusion. This patch supersede previous patch which is trying different direction [3], and please remove [2] from mm-unstable branch when applying this patch. Finally, I would like to express my gratitude to David Rheinsberg and Barnabás Pőcze for initiating the discussion on the topic of sealability. [1] https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ [2] https://lore.kernel.org/lkml/20240513191544.94754-1-pobrn@protonmail.com/ [3] https://lore.kernel.org/lkml/20240524033933.135049-1-jeffxu@google.com/ v2: Update according to Randy Dunlap' comments. v1: https://lore.kernel.org/linux-mm/20240607203543.2151433-1-jeffxu@google.com/ Jeff Xu (1): mm/memfd: add documentation for MFD_NOEXEC_SEAL MFD_EXEC Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/mfd_noexec.rst | 86 ++++++++++++++++++++++ 2 files changed, 87 insertions(+) create mode 100644 Documentation/userspace-api/mfd_noexec.rst -- 2.45.2.505.gda0bf45e8d-goog

7 months, 1 week

3
3
0 0

[PATCH v2 0/2] selftests/openat2, fchmodat2: fix clang build failures

by John Hubbard

These two subsystems require very similar fixes, so I'm sending them out together. Changes since the first version: 1) Rebased onto Linux 6.10-rc1. 2) Added a Reviewed-by tag from Ryan Roberts. See [1] for that. Related work: I've sent a separate fix that allows "make CC=clang" to work in addition to "make LLVM=1" [2]. [1] https://lore.kernel.org/518dd1e3-e31a-41c3-b488-9b75a64b6c8a@arm.com [2] https://lore.kernel.org/20240531183751.100541-2-jhubbard@nvidia.com John Hubbard (2): selftests/openat2: fix clang build failures: -static-libasan, LOCAL_HDRS selftests/fchmodat2: fix clang build failure due to -static-libasan tools/testing/selftests/fchmodat2/Makefile | 11 ++++++++++- tools/testing/selftests/openat2/Makefile | 14 ++++++++++++-- 2 files changed, 22 insertions(+), 3 deletions(-) base-commit: cc8ed4d0a8486c7472cd72ec3c19957e509dc68c -- 2.45.1

7 months, 1 week

3
6
0 0

[PATCH] selftests/sched: fix code format issues

by aigourensheng

There are extra spaces in the middle of #define. It is recommended to delete the spaces to make the code look more comfortable. Signed-off-by: aigourensheng <shechenglong001(a)gmail.com> --- tools/testing/selftests/sched/cs_prctl_test.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/sched/cs_prctl_test.c b/tools/testing/selftests/sched/cs_prctl_test.c index 62fba7356af2..52d97fae4dbd 100644 --- a/tools/testing/selftests/sched/cs_prctl_test.c +++ b/tools/testing/selftests/sched/cs_prctl_test.c @@ -42,11 +42,11 @@ static pid_t gettid(void) #ifndef PR_SCHED_CORE #define PR_SCHED_CORE 62 -# define PR_SCHED_CORE_GET 0 -# define PR_SCHED_CORE_CREATE 1 /* create unique core_sched cookie */ -# define PR_SCHED_CORE_SHARE_TO 2 /* push core_sched cookie to pid */ -# define PR_SCHED_CORE_SHARE_FROM 3 /* pull core_sched cookie to pid */ -# define PR_SCHED_CORE_MAX 4 +#define PR_SCHED_CORE_GET 0 +#define PR_SCHED_CORE_CREATE 1 /* create unique core_sched cookie */ +#define PR_SCHED_CORE_SHARE_TO 2 /* push core_sched cookie to pid */ +#define PR_SCHED_CORE_SHARE_FROM 3 /* pull core_sched cookie to pid */ +#define PR_SCHED_CORE_MAX 4 #endif #define MAX_PROCESSES 128 -- 2.17.1

7 months, 1 week

2
1
0 0

[PATCH bpf-next v3 00/11] Add check for bpf lsm return value

by Xu Kuohai

From: Xu Kuohai <xukuohai(a)huawei.com> A bpf prog returning positive number attached to file_alloc_security hook will make kernel panic. Here is a panic log: [ 441.235774] BUG: kernel NULL pointer dereference, address: 00000000000009 [ 441.236748] #PF: supervisor write access in kernel mode [ 441.237429] #PF: error_code(0x0002) - not-present page [ 441.238119] PGD 800000000b02f067 P4D 800000000b02f067 PUD b031067 PMD 0 [ 441.238990] Oops: 0002 [#1] PREEMPT SMP PTI [ 441.239546] CPU: 0 PID: 347 Comm: loader Not tainted 6.8.0-rc6-gafe0cbf23373 #22 [ 441.240496] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b4 [ 441.241933] RIP: 0010:alloc_file+0x4b/0x190 [ 441.242485] Code: 8b 04 25 c0 3c 1f 00 48 8b b0 30 0c 00 00 e8 9c fe ff ff 48 3d 00 f0 ff fb [ 441.244820] RSP: 0018:ffffc90000c67c40 EFLAGS: 00010203 [ 441.245484] RAX: ffff888006a891a0 RBX: ffffffff8223bd00 RCX: 0000000035b08000 [ 441.246391] RDX: ffff88800b95f7b0 RSI: 00000000001fc110 RDI: f089cd0b8088ffff [ 441.247294] RBP: ffffc90000c67c58 R08: 0000000000000001 R09: 0000000000000001 [ 441.248209] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000001 [ 441.249108] R13: ffffc90000c67c78 R14: ffffffff8223bd00 R15: fffffffffffffff4 [ 441.250007] FS: 00000000005f3300(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 441.251053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 441.251788] CR2: 00000000000001a9 CR3: 000000000bdc4003 CR4: 0000000000170ef0 [ 441.252688] Call Trace: [ 441.253011] <TASK> [ 441.253296] ? __die+0x24/0x70 [ 441.253702] ? page_fault_oops+0x15b/0x480 [ 441.254236] ? fixup_exception+0x26/0x330 [ 441.254750] ? exc_page_fault+0x6d/0x1c0 [ 441.255257] ? asm_exc_page_fault+0x26/0x30 [ 441.255792] ? alloc_file+0x4b/0x190 [ 441.256257] alloc_file_pseudo+0x9f/0xf0 [ 441.256760] __anon_inode_getfile+0x87/0x190 [ 441.257311] ? lock_release+0x14e/0x3f0 [ 441.257808] bpf_link_prime+0xe8/0x1d0 [ 441.258315] bpf_tracing_prog_attach+0x311/0x570 [ 441.258916] ? __pfx_bpf_lsm_file_alloc_security+0x10/0x10 [ 441.259605] __sys_bpf+0x1bb7/0x2dc0 [ 441.260070] __x64_sys_bpf+0x20/0x30 [ 441.260533] do_syscall_64+0x72/0x140 [ 441.261004] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 441.261643] RIP: 0033:0x4b0349 [ 441.262045] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 88 [ 441.264355] RSP: 002b:00007fff74daee38 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ 441.265293] RAX: ffffffffffffffda RBX: 00007fff74daef30 RCX: 00000000004b0349 [ 441.266187] RDX: 0000000000000040 RSI: 00007fff74daee50 RDI: 000000000000001c [ 441.267114] RBP: 000000000000001b R08: 00000000005ef820 R09: 0000000000000000 [ 441.268018] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004 [ 441.268907] R13: 0000000000000004 R14: 00000000005ef018 R15: 00000000004004e8 The reason is that the positive number returned by bpf prog is not a valid errno, and could not be filtered out with IS_ERR which is used by the file system to check errors. As a result, the filesystem mistakenly uses this random positive number as file pointer, causing panic. To fix this issue, there are two schemes: 1. Modify the calling sites of file_alloc_security to take positive return values as zero. 2. Make the bpf verifier to ensure no unpredicted value returned by lsm bpf prog. Considering that hook file_alloc_security never returned positive number before bpf lsm was introduced, and other lsm hooks may have the same problem, scheme 2 is more reasonable. So this series adds lsm return value check in verifier to fix it. v3: 1. Fix incorrect lsm hook return value ranges, and add disabled hook list for bpf lsm, and merge two LSM_RET_INT patches. (KP Singh) 2. Avoid bpf lsm progs attached to different hooks to call each other with tail call 3. Fix a CI failure caused by false rejection of AND operation 4. Add tests v2: https://lore.kernel.org/bpf/20240325095653.1720123-1-xukuohai@huaweicloud.c… fix bpf ci failure v1: https://lore.kernel.org/bpf/20240316122359.1073787-1-xukuohai@huaweicloud.c… Xu Kuohai (11): bpf, lsm: Annotate lsm hook return value range bpf, lsm: Add helper to read lsm hook return value range bpf, lsm: Check bpf lsm hook return values in verifier bpf, lsm: Add bpf lsm disabled hook list bpf: Avoid progs for different hooks calling each other with tail call bpf: Fix compare error in function retval_range_within bpf: Fix a false rejection caused by AND operation selftests/bpf: Avoid load failure for token_lsm.c selftests/bpf: Add return value checks for failed tests selftests/bpf: Add test for lsm tail call selftests/bpf: Add verifier tests for bpf lsm include/linux/bpf.h | 2 + include/linux/bpf_lsm.h | 8 + include/linux/lsm_hook_defs.h | 591 +++++++++--------- include/linux/lsm_hooks.h | 6 - kernel/bpf/bpf_lsm.c | 84 ++- kernel/bpf/btf.c | 5 +- kernel/bpf/core.c | 22 +- kernel/bpf/verifier.c | 82 ++- security/security.c | 1 + .../selftests/bpf/prog_tests/test_lsm.c | 46 +- .../selftests/bpf/prog_tests/verifier.c | 3 +- tools/testing/selftests/bpf/progs/err.h | 10 + .../selftests/bpf/progs/lsm_tailcall.c | 34 + .../selftests/bpf/progs/test_sig_in_xattr.c | 4 + .../bpf/progs/test_verify_pkcs7_sig.c | 8 +- tools/testing/selftests/bpf/progs/token_lsm.c | 4 +- .../bpf/progs/verifier_global_subprogs.c | 7 +- .../selftests/bpf/progs/verifier_lsm.c | 155 +++++ 18 files changed, 754 insertions(+), 318 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/lsm_tailcall.c create mode 100644 tools/testing/selftests/bpf/progs/verifier_lsm.c -- 2.30.2

7 months, 1 week

8
37
0 0

[PATCH v1 0/3] Userspace controls soft-offline HugeTLB pages

by Jiaqi Yan

Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC, but with two pain points to users: 1. Correction usually happens on the fly and adds latency overhead 2. Not-fully-proved theory states excessive correctable memory errors can develop into uncorrectable memory error. Soft offline is kernel's additional solution for memory pages having (excessive) corrected memory errors. Impacted page is migrated to healthy page if it is in use, then the original page is discarded for any future use. The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of HugeTLB hugepages. Soft-offline dissolves a hugepage, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later mmap hugepages MAP_FAILED due to lack of hugepages. In addition, discarding the entire 1G memory page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases: 1. GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER. 2. RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery. This patch series give userspace the control of soft-offlining HugeTLB pages: kernel only soft offlines hugepage if userspace has opt-ed in for that specific hugepage size, and exposed to userspace by a new sysfs entry called softoffline_corrected_errors under /sys/kernel/mm/hugepages/hugepages-${size}kB directory: * When softoffline_corrected_errors=0, skip soft offlining for all hugepages of size ${size}kB. * When softoffline_corrected_errors=1, soft offline as before this patch series. By default softoffline_corrected_errors is 1. This patch set is based at commit a52b4f11a2e1 ("selftest mm/mseal read-only elf memory segment"). Jiaqi Yan (3): mm/memory-failure: userspace controls soft-offlining hugetlb pages selftest/mm: test softoffline_corrected_errors behaviors docs: hugetlbpage.rst: add softoffline_corrected_errors Documentation/admin-guide/mm/hugetlbpage.rst | 15 +- include/linux/hugetlb.h | 17 ++ mm/hugetlb.c | 34 +++ mm/memory-failure.c | 7 + tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + .../selftests/mm/hugetlb-soft-offline.c | 262 ++++++++++++++++++ tools/testing/selftests/mm/run_vmtests.sh | 4 + 8 files changed, 340 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/mm/hugetlb-soft-offline.c -- 2.45.1.288.g0e0cd299f1-goog

7 months, 1 week

3
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror