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

[RESEND bpf-next v2] selftests/bpf:fix a resource leak

by Zhu Jun

The requested resources should be closed before return in main(), otherwise resource leak will occur Signed-off-by: Zhu Jun <zhujun2(a)cmss.chinamobile.com> --- Changes in v2: - check for cg_fd >= 0 and have just one out label tools/testing/selftests/bpf/test_sockmap.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/bpf/test_sockmap.c b/tools/testing/selftests/bpf/test_sockmap.c index a34e95040994..285a9a714666 100644 --- a/tools/testing/selftests/bpf/test_sockmap.c +++ b/tools/testing/selftests/bpf/test_sockmap.c @@ -2075,8 +2075,10 @@ int main(int argc, char **argv) if (!cg_fd) { cg_fd = cgroup_setup_and_join(CG_PATH); - if (cg_fd < 0) - return cg_fd; + if (cg_fd < 0) { + err = cg_fd; + goto out; + } cg_created = 1; } @@ -2092,7 +2094,7 @@ int main(int argc, char **argv) if (err) { fprintf(stderr, "populate program: (%s) %s\n", bpf_file, strerror(errno)); - return 1; + goto out; } running = 1; @@ -2109,7 +2111,8 @@ int main(int argc, char **argv) free(options.whitelist); if (options.blacklist) free(options.blacklist); - close(cg_fd); + if (cg_fd >= 0) + close(cg_fd); if (cg_created) cleanup_cgroup_environment(); return err; -- 2.17.1

9 months, 1 week

1
0
0 0

[PATCH bpf-next v1] selftests/bpf: Fix wrong binary in Makefile log output

by Tony Ambardar

Make log output incorrectly shows 'test_maps' as the binary name for every 'CLNG-BPF' build step, apparently picking up the last value defined for the $(TRUNNER_BINARY) variable. Update the 'CLANG_BPF_BUILD_RULE' variants to fix this confusing output. Current output: CLNG-BPF [test_maps] access_map_in_map.bpf.o GEN-SKEL [test_progs] access_map_in_map.skel.h ... CLNG-BPF [test_maps] access_map_in_map.bpf.o GEN-SKEL [test_progs-no_alu32] access_map_in_map.skel.h ... CLNG-BPF [test_maps] access_map_in_map.bpf.o GEN-SKEL [test_progs-cpuv4] access_map_in_map.skel.h After fix: CLNG-BPF [test_progs] access_map_in_map.bpf.o GEN-SKEL [test_progs] access_map_in_map.skel.h ... CLNG-BPF [test_progs-no_alu32] access_map_in_map.bpf.o GEN-SKEL [test_progs-no_alu32] access_map_in_map.skel.h ... CLNG-BPF [test_progs-cpuv4] access_map_in_map.bpf.o GEN-SKEL [test_progs-cpuv4] access_map_in_map.skel.h Fixes: a5d0c26a2784 ("selftests/bpf: Add a cpuv4 test runner for cpu=v4 testing") Fixes: 89ad7420b25c ("selftests/bpf: Drop the need for LLVM's llc") Signed-off-by: Tony Ambardar <tony.ambardar(a)gmail.com> --- tools/testing/selftests/bpf/Makefile | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index 0b4bfbc0ef68..67921e3367dd 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -425,27 +425,28 @@ $(OUTPUT)/flow_dissector_load.o: flow_dissector_load.h $(OUTPUT)/cgroup_getset_retval_hooks.o: cgroup_getset_retval_hooks.h # Build BPF object using Clang -# $1 - input .c file -# $2 - output .o file -# $3 - CFLAGS +# $1 - binary name +# $2 - input .c file +# $3 - output .o file +# $4 - CFLAGS define CLANG_BPF_BUILD_RULE - $(call msg,CLNG-BPF,$(TRUNNER_BINARY),$2) - $(Q)$(CLANG) $3 -O2 --target=bpf -c $1 -mcpu=v3 -o $2 + $(call msg,CLNG-BPF,$1,$3) + $(Q)$(CLANG) $4 -O2 --target=bpf -c $2 -mcpu=v3 -o $3 endef # Similar to CLANG_BPF_BUILD_RULE, but with disabled alu32 define CLANG_NOALU32_BPF_BUILD_RULE - $(call msg,CLNG-BPF,$(TRUNNER_BINARY),$2) - $(Q)$(CLANG) $3 -O2 --target=bpf -c $1 -mcpu=v2 -o $2 + $(call msg,CLNG-BPF,$1,$3) + $(Q)$(CLANG) $4 -O2 --target=bpf -c $2 -mcpu=v2 -o $3 endef # Similar to CLANG_BPF_BUILD_RULE, but with cpu-v4 define CLANG_CPUV4_BPF_BUILD_RULE - $(call msg,CLNG-BPF,$(TRUNNER_BINARY),$2) - $(Q)$(CLANG) $3 -O2 --target=bpf -c $1 -mcpu=v4 -o $2 + $(call msg,CLNG-BPF,$1,$3) + $(Q)$(CLANG) $4 -O2 --target=bpf -c $2 -mcpu=v4 -o $3 endef # Build BPF object using GCC define GCC_BPF_BUILD_RULE - $(call msg,GCC-BPF,$(TRUNNER_BINARY),$2) - $(Q)$(BPF_GCC) $3 -DBPF_NO_PRESERVE_ACCESS_INDEX -Wno-attributes -O2 -c $1 -o $2 + $(call msg,GCC-BPF,$1,$3) + $(Q)$(BPF_GCC) $4 -DBPF_NO_PRESERVE_ACCESS_INDEX -Wno-attributes -O2 -c $2 -o $3 endef SKEL_BLACKLIST := btf__% test_pinning_invalid.c test_sk_assign.c @@ -534,7 +535,7 @@ $(TRUNNER_BPF_OBJS): $(TRUNNER_OUTPUT)/%.bpf.o: \ $(wildcard $(BPFDIR)/bpf_*.h) \ $(wildcard $(BPFDIR)/*.bpf.h) \ | $(TRUNNER_OUTPUT) $$(BPFOBJ) - $$(call $(TRUNNER_BPF_BUILD_RULE),$$<,$$@, \ + $$(call $(TRUNNER_BPF_BUILD_RULE),$(TRUNNER_BINARY),$$<,$$@, \ $(TRUNNER_BPF_CFLAGS) \ $$($$<-CFLAGS) \ $$($$<-$2-CFLAGS)) -- 2.34.1

9 months, 1 week

4
8
0 0

[PATCH bpf-next v1 0/2] selftests/bpf: Add support for MIPS systems

by Tony Ambardar

Hello, This series includes two fixes to support builds targeting MIPS systems. The patches have been tested both with the kernel-patches/bpf CI and locally using mips64el-gcc/musl-libc and QEMU with an OpenWrt rootfs. Patch 1 adds support for MIPS system includes when compiling BPF. Patch 2 fixes a MIPS GOT issue when linking uprobe_multi. Feedback and suggestions for improvement are welcome! Thanks, Tony Tony Ambardar (2): selftests/bpf: Add missing system defines for mips selftests/bpf: Fix error linking uprobe_multi on mips tools/testing/selftests/bpf/Makefile | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) -- 2.34.1

9 months, 1 week

3
8
0 0

mm, memcg: cg2 memory{.swap,}.peak write handlers

by David Finkel

This is an updated patchset following some excellent comments from Roman and Longman. [1] As suggested, I've broken this into two commits: 1) with the implementation changes 2) extending the tests tests I haven't been able to induce anything problematic, but I'm a bit unclear as to whether there's reference counting on cgroups such that we don't need to handle the case where the cgroup is freed before the one of the peak files is closed. Documentation/admin-guide/cgroup-v2.rst | 26 ++- include/linux/cgroup.h | 8 + include/linux/memcontrol.h | 5 + include/linux/page_counter.h | 11 +- kernel/cgroup/cgroup-internal.h | 2 + kernel/cgroup/cgroup.c | 7 + mm/memcontrol.c | 129 +++++++++++++-- mm/page_counter.c | 36 ++++- tools/testing/selftests/cgroup/cgroup_util.c | 22 +++ tools/testing/selftests/cgroup/cgroup_util.h | 2 + tools/testing/selftests/cgroup/test_memcontrol.c | 227 ++++++++++++++++++++++++++- 11 files changed, 444 insertions(+), 31 deletions(-) [1]: https://lore.kernel.org/cgroups/20240722151713.2724855-1-davidf@vimeo.com/T/ Thank you for your efforts and reviews, David Finkel Senior Principal Software Engineer Vimeo Inc.

9 months, 1 week

2
4
0 0

[PATCH bpf-next 0/4] use network helpers, part 10

by Geliang Tang

From: Geliang Tang <tanggeliang(a)kylinos.cn> This set is part 10 of series "use network helpers" all BPF selftests wide. Patches 1-3 drop local functions make_client(), make_socket() and inetaddr_len() in sk_lookup.c. Patch 4 drops a useless function __start_server() in network_helpers.c. Geliang Tang (4): selftests/bpf: Drop make_client in sk_lookup selftests/bpf: Drop make_socket in sk_lookup selftests/bpf: Drop inetaddr_len in sk_lookup selftests/bpf: Drop __start_server in network_helpers tools/testing/selftests/bpf/network_helpers.c | 26 ++--- .../selftests/bpf/prog_tests/sk_lookup.c | 110 +++++------------- 2 files changed, 40 insertions(+), 96 deletions(-) -- 2.43.0

9 months, 1 week

2
5
0 0

[PATCH bpf-next v4 00/20] Add return value range check for BPF LSM

by Xu Kuohai

From: Xu Kuohai <xukuohai(a)huawei.com> LSM BPF prog returning a positive number attached to the hook file_alloc_security makes 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 This is because the filesystem uses IS_ERR to check if the return value is an error code. If it is not, the filesystem takes the return value as a file pointer. Since the positive number returned by the BPF prog is not a real file pointer, this misinterpretation causes a panic. Since other LSM modules always return either a negative error code or a valid pointer, this specific issue only exists in BPF LSM. The proposed solution is to reject LSM BPF progs returning unexpected values in the verifier. This patch set adds return value check to ensure only BPF progs returning expected values are accepted. Since each LSM hook has different excepted return values, we need to know the expected return values for each individual hook to do the check. Earlier versions of the patch set used LSM hook annotations to specify the return value range for each hook. Based on Paul's suggestion, current version gets rid of such annotations and instead converts hook return values to a common pattern: return 0 on success and negative error code on failure. Basically, LSM hooks are divided into two types: hooks that return a negative error code and zero or other values, and hooks that do not return a negative error code. This patch set converts all hooks of the first type and part of the second type to return 0 on success and a negative error code on failure (see patches 1-10). For certain hooks, like ismaclabel and inode_xattr_skipcap, the hook name already imply that returning 0 or 1 is the best choice, so they are not converted. There are four unconverted hooks. Except for ismaclabel, which is not used by BPF LSM, the other three are specified with a BTF ID list to only return 0 or 1. v4: 1. remove LSM_HOOK return value annotaion and convert LSM hook return value to a common patern: return 0 on success and negative error code on failure (patch 1-10) 2. enable BPF LSM progs to read and write output params (patch 12) 3. add a special case for bitwise AND on range [-1, 0] (patch 16) 4. add a 32-bit comparing flag for retval_range_within (patch 15) 5. collect ACKs, style fix, etc v3: https://lore.kernel.org/bpf/20240411122752.2873562-1-xukuohai@huaweicloud.c… 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 (20): lsm: Refactor return value of LSM hook vm_enough_memory lsm: Refactor return value of LSM hook inode_need_killpriv lsm: Refactor return value of LSM hook inode_getsecurity lsm: Refactor return value of LSM hook inode_listsecurity lsm: Refactor return value of LSM hook inode_copy_up_xattr lsm: Refactor return value of LSM hook getselfattr lsm: Refactor return value of LSM hook setprocattr lsm: Refactor return value of LSM hook getprocattr lsm: Refactor return value of LSM hook key_getsecurity lsm: Refactor return value of LSM hook audit_rule_match bpf, lsm: Add disabled BPF LSM hook list bpf, lsm: Enable BPF LSM prog to read/write return value parameters bpf, lsm: Add check for BPF LSM return value bpf: Prevent tail call between progs attached to different hooks bpf: Fix compare error in function retval_range_within bpf: Add a special case for bitwise AND on range [-1, 0] 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 fs/attr.c | 5 +- fs/inode.c | 4 +- fs/nfs/nfs4proc.c | 5 +- fs/overlayfs/copy_up.c | 6 +- fs/proc/base.c | 10 +- fs/xattr.c | 24 +- include/linux/bpf.h | 2 + include/linux/bpf_lsm.h | 15 + include/linux/lsm_hook_defs.h | 22 +- include/linux/security.h | 62 ++-- include/linux/tnum.h | 3 + kernel/bpf/bpf_lsm.c | 64 +++- kernel/bpf/btf.c | 21 +- kernel/bpf/core.c | 21 +- kernel/bpf/tnum.c | 25 ++ kernel/bpf/verifier.c | 173 ++++++++++- net/socket.c | 9 +- security/apparmor/audit.c | 22 +- security/apparmor/include/audit.h | 2 +- security/apparmor/lsm.c | 22 +- security/commoncap.c | 32 +- security/integrity/evm/evm_main.c | 2 +- security/keys/keyctl.c | 11 +- security/lsm_syscalls.c | 6 +- security/security.c | 167 ++++++++--- security/selinux/hooks.c | 94 +++--- security/selinux/include/audit.h | 8 +- security/selinux/ss/services.c | 54 ++-- security/smack/smack_lsm.c | 104 ++++--- .../selftests/bpf/prog_tests/test_lsm.c | 46 ++- .../selftests/bpf/prog_tests/verifier.c | 2 + 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 | 274 ++++++++++++++++++ 38 files changed, 1098 insertions(+), 286 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

9 months, 1 week

6
46
0 0

[PATCH v4 0/2] Add test to distinguish between thread's signal mask and ucontext_t

by Dev Jain

This patch series is motivated by the following observation: Raise a signal, jump to signal handler. The ucontext_t structure dumped by kernel to userspace has a uc_sigmask field having the mask of blocked signals. If you run a fresh minimalistic program doing this, this field is empty, even if you block some signals while registering the handler with sigaction(). Here is what the man-pages have to say: sigaction(2): "sa_mask specifies a mask of signals which should be blocked (i.e., added to the signal mask of the thread in which the signal handler is invoked) during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER flag is used." signal(7): Under "Execution of signal handlers", (1.3) implies: "The thread's current signal mask is accessible via the ucontext_t object that is pointed to by the third argument of the signal handler." But, (1.4) states: "Any signals specified in act->sa_mask when registering the handler with sigprocmask(2) are added to the thread's signal mask. The signal being delivered is also added to the signal mask, unless SA_NODEFER was specified when registering the handler. These signals are thus blocked while the handler executes." There clearly is no distinction being made in the man pages between "Thread's signal mask" and ucontext_t; this logically should imply that a signal blocked by populating struct sigaction should be visible in ucontext_t. Here is what the kernel code does (for Aarch64): do_signal() -> handle_signal() -> sigmask_to_save(), which returns &current->blocked, is passed to setup_rt_frame() -> setup_sigframe() -> __copy_to_user(). Hence, &current->blocked is copied to ucontext_t exposed to userspace. Returning back to handle_signal(), signal_setup_done() -> signal_delivered() -> sigorsets() and set_current_blocked() are responsible for using information from struct ksignal ksig, which was populated through the sigaction() system call in kernel/signal.c: copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)), to update &current->blocked; hence, the set of blocked signals for the current thread is updated AFTER the kernel dumps ucontext_t to userspace. Assuming that the above is indeed the intended behaviour, because it semantically makes sense, since the signals blocked using sigaction() remain blocked only till the execution of the handler, and not in the context present before jumping to the handler (but nothing can be confirmed from the man-pages), the series introduces a test for mangling with uc_sigmask. I will send a separate series to fix the man-pages. The proposed selftest has been tested out on Aarch32, Aarch64 and x86_64. v3->v4: - Allocate sigsets as automatic variables to avoid malloc() v2->v3: - ucontext describes current state -> ucontext describes interrupted context - Add a comment for blockage of USR2 even after return from handler - Describe blockage of signals in a better way v1->v2: - Replace all occurrences of SIGPIPE with SIGSEGV - Fixed a mismatch between code comment and ksft log - Add a testcase: Raise the same signal again; it must not be queued - Remove unneeded <assert.h>, <unistd.h> - Give a detailed test description in the comments; also describe the exact meaning of delivered and blocked - Handle errors for all libc functions/syscalls - Mention tests in Makefile and .gitignore in alphabetical order v1: - https://lore.kernel.org/all/20240607122319.768640-1-dev.jain@arm.com/ Dev Jain (2): selftests: Rename sigaltstack to generic signal selftests: Add a test mangling with uc_sigmask tools/testing/selftests/Makefile | 2 +- .../{sigaltstack => signal}/.gitignore | 3 +- .../{sigaltstack => signal}/Makefile | 3 +- .../current_stack_pointer.h | 0 .../selftests/signal/mangle_uc_sigmask.c | 186 ++++++++++++++++++ .../sas.c => signal/sigaltstack.c} | 0 6 files changed, 191 insertions(+), 3 deletions(-) rename tools/testing/selftests/{sigaltstack => signal}/.gitignore (57%) rename tools/testing/selftests/{sigaltstack => signal}/Makefile (53%) rename tools/testing/selftests/{sigaltstack => signal}/current_stack_pointer.h (100%) create mode 100644 tools/testing/selftests/signal/mangle_uc_sigmask.c rename tools/testing/selftests/{sigaltstack/sas.c => signal/sigaltstack.c} (100%) -- 2.34.1

9 months, 1 week

4
9
0 0

[PATCH] kselftest: missing arg in ptrace.c

by Remington Brasga

The string passed to ksft_test_result_skip is missing the `type_name` Signed-off-by: Remington Brasga <rbrasga(a)uci.edu> --- clang-tidy reported clang-diagnostic-format-insufficient-args warning on this line, so I am fixing it. tools/testing/selftests/arm64/abi/ptrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/arm64/abi/ptrace.c b/tools/testing/selftests/arm64/abi/ptrace.c index abe4d58d731d..6144f83f8ab4 100644 --- a/tools/testing/selftests/arm64/abi/ptrace.c +++ b/tools/testing/selftests/arm64/abi/ptrace.c @@ -156,7 +156,7 @@ static void test_hw_debug(pid_t child, int type, const char *type_name) /* Zero is not currently architecturally valid */ ksft_test_result(arch, "%s_arch_set\n", type_name); } else { - ksft_test_result_skip("%s_arch_set\n"); + ksft_test_result_skip("%s_arch_set\n", type_name); } } -- 2.34.1

9 months, 1 week

4
6
0 0

Recommendations for Optimizing Linux Kernel for ARM Architecture

by Selena Thomas

Hi everyone, I'm currently working on optimizing the Linux kernel for an ARM-based project and would appreciate some guidance. I've already gone through the basics of kernel configuration, but I'm looking for more advanced tips. Specifically, I'm interested in: Best practices for enabling/disabling specific kernel features for ARM. Effective ways to profile and analyze performance bottlenecks. Recommendations for debugging tools tailored for ARM architecture. Any common pitfalls to avoid during the optimization process. If you have any experiences or resources to share, I'd be very grateful. Looking forward to your insights! Best, Selena Thomas https://www.igmguru.com/data-science-bi/msbi-certification-training/

9 months, 1 week

1
0
0 0

Recommendations for Optimizing Linux Kernel for ARM Architecture

by Selena Thomas

Hi everyone, I'm currently working on optimizing the Linux kernel for an ARM-based project and would appreciate some guidance. I've already gone through the basics of kernel configuration, but I'm looking for more advanced tips. Specifically, I'm interested in: Best practices for enabling/disabling specific kernel features for ARM. Effective ways to profile and analyze performance bottlenecks. Recommendations for debugging tools tailored for ARM architecture. Any common pitfalls to avoid during the optimization process. If you have any experiences or resources to share, I'd be very grateful. Looking forward to your insights! Best regards Selena

9 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror