#
229087f6 |
| 04-Apr-2024 |
Andrii Nakryiko <andrii@kernel.org> |
bpf, kconfig: Fix DEBUG_INFO_BTF_MODULES Kconfig definition
Turns out that due to CONFIG_DEBUG_INFO_BTF_MODULES not having an explicitly specified "menu item name" in Kconfig, it's basically impossi
bpf, kconfig: Fix DEBUG_INFO_BTF_MODULES Kconfig definition
Turns out that due to CONFIG_DEBUG_INFO_BTF_MODULES not having an explicitly specified "menu item name" in Kconfig, it's basically impossible to turn it off (see [0]).
This patch fixes the issue by defining menu name for CONFIG_DEBUG_INFO_BTF_MODULES, which makes it actually adjustable and independent of CONFIG_DEBUG_INFO_BTF, in the sense that one can have DEBUG_INFO_BTF=y and DEBUG_INFO_BTF_MODULES=n.
We still keep it as defaulting to Y, of course.
Fixes: 5f9ae91f7c0d ("kbuild: Build kernel module BTFs if BTF is enabled and pahole supports it") Reported-by: Vincent Li <vincent.mc.li@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/CAK3+h2xiFfzQ9UXf56nrRRP=p1+iUxGoEP5B+aq9MDT5jLXDSg@mail.gmail.com [0] Link: https://lore.kernel.org/bpf/20240404220344.3879270-1-andrii@kernel.org
show more ...
|
#
acd80cdc |
| 14-Mar-2024 |
Guenter Roeck <linux@roeck-us.net> |
Revert "kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST"
This reverts commit 4acf1de35f41549e60c3c02a8defa7cb95eabdf2.
Commit d055c6a2cc16 ("kunit: memcpy: Mark tests as slow usi
Revert "kunit: memcpy: Split slow memcpy tests into MEMCPY_SLOW_KUNIT_TEST"
This reverts commit 4acf1de35f41549e60c3c02a8defa7cb95eabdf2.
Commit d055c6a2cc16 ("kunit: memcpy: Mark tests as slow using test attributes") marks slow memcpy unit tests as slow. Since this commit, the tests can be disabled with a module parameter, and the configuration option to skip the slow tests is no longer needed. Revert the patch introducing it.
Cc: David Gow <davidgow@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240314151200.2285314-1-linux@roeck-us.net Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
fb57550f |
| 01-Mar-2024 |
Kees Cook <keescook@chromium.org> |
string: Convert helpers selftest to KUnit
Convert test-string_helpers.c to KUnit so it can be easily run with everything else.
Failure reporting doesn't need to be open-coded in most places, for ex
string: Convert helpers selftest to KUnit
Convert test-string_helpers.c to KUnit so it can be easily run with everything else.
Failure reporting doesn't need to be open-coded in most places, for example, forcing a failure in the expected output for upper/lower testing looks like this:
[12:18:43] # test_upper_lower: EXPECTATION FAILED at lib/string_helpers_kunit.c:579 [12:18:43] Expected dst == strings_upper[i].out, but [12:18:43] dst == "ABCDEFGH1234567890TEST" [12:18:43] strings_upper[i].out == "ABCDEFGH1234567890TeST" [12:18:43] [FAILED] test_upper_lower
Currently passes without problems:
$ ./tools/testing/kunit/kunit.py run string_helpers ... [12:23:55] Starting KUnit Kernel (1/1)... [12:23:55] ============================================================ [12:23:55] =============== string_helpers (3 subtests) ================ [12:23:55] [PASSED] test_get_size [12:23:55] [PASSED] test_upper_lower [12:23:55] [PASSED] test_unescape [12:23:55] ================= [PASSED] string_helpers ================== [12:23:55] ============================================================ [12:23:55] Testing complete. Ran 3 tests: passed: 3 [12:23:55] Elapsed time: 6.709s total, 0.001s configuring, 6.591s building, 0.066s running
Link: https://lore.kernel.org/r/20240301202732.2688342-2-keescook@chromium.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
29d85688 |
| 01-Mar-2024 |
Kees Cook <keescook@chromium.org> |
string: Convert selftest to KUnit
Convert test_string.c to KUnit so it can be easily run with everything else.
Additional text context is retained for failure reporting. For example, when forcing a
string: Convert selftest to KUnit
Convert test_string.c to KUnit so it can be easily run with everything else.
Additional text context is retained for failure reporting. For example, when forcing a bad match, we can see the loop counters reported for the memset() tests:
[09:21:52] # test_memset64: ASSERTION FAILED at lib/string_kunit.c:93 [09:21:52] Expected v == 0xa2a1a1a1a1a1a1a1ULL, but [09:21:52] v == -6799976246779207263 (0xa1a1a1a1a1a1a1a1) [09:21:52] 0xa2a1a1a1a1a1a1a1ULL == -6727918652741279327 (0xa2a1a1a1a1a1a1a1) [09:21:52] i:0 j:0 k:0 [09:21:52] [FAILED] test_memset64
Currently passes without problems:
$ ./tools/testing/kunit/kunit.py run string ... [09:37:40] Starting KUnit Kernel (1/1)... [09:37:40] ============================================================ [09:37:40] =================== string (6 subtests) ==================== [09:37:40] [PASSED] test_memset16 [09:37:40] [PASSED] test_memset32 [09:37:40] [PASSED] test_memset64 [09:37:40] [PASSED] test_strchr [09:37:40] [PASSED] test_strnchr [09:37:40] [PASSED] test_strspn [09:37:40] ===================== [PASSED] string ====================== [09:37:40] ============================================================ [09:37:40] Testing complete. Ran 6 tests: passed: 6 [09:37:40] Elapsed time: 6.730s total, 0.001s configuring, 6.562s building, 0.131s running
Link: https://lore.kernel.org/r/20240301202732.2688342-1-keescook@chromium.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
1a78f8cb |
| 07-Apr-2023 |
Kees Cook <keescook@chromium.org> |
fortify: Allow KUnit test to build without FORTIFY
In order for CI systems to notice all the skipped tests related to CONFIG_FORTIFY_SOURCE, allow the FORTIFY_SOURCE KUnit tests to build with or wit
fortify: Allow KUnit test to build without FORTIFY
In order for CI systems to notice all the skipped tests related to CONFIG_FORTIFY_SOURCE, allow the FORTIFY_SOURCE KUnit tests to build with or without CONFIG_FORTIFY_SOURCE.
Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
f22f7132 |
| 22-Feb-2024 |
Waiman Long <longman@redhat.com> |
locking/rwsem: Make DEBUG_RWSEMS and PREEMPT_RT mutually exclusive
The debugging code enabled by CONFIG_DEBUG_RWSEMS=y will only be compiled in when CONFIG_PREEMPT_RT isn't set. There is no point to
locking/rwsem: Make DEBUG_RWSEMS and PREEMPT_RT mutually exclusive
The debugging code enabled by CONFIG_DEBUG_RWSEMS=y will only be compiled in when CONFIG_PREEMPT_RT isn't set. There is no point to allow CONFIG_DEBUG_RWSEMS to be set in a kernel configuration where CONFIG_PREEMPT_RT is also set. Make them mutually exclusive.
Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20240222150540.79981-5-longman@redhat.com
show more ...
|
#
9feceff1 |
| 25-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
lib/Kconfig.debug: update Clang version check in CONFIG_KCOV
Now that the minimum supported version of LLVM for building the kernel has been bumped to 13.0.1, this condition can be changed to just C
lib/Kconfig.debug: update Clang version check in CONFIG_KCOV
Now that the minimum supported version of LLVM for building the kernel has been bumped to 13.0.1, this condition can be changed to just CONFIG_CC_IS_CLANG, as the build will fail during the configuration stage for older LLVM versions.
Link: https://lkml.kernel.org/r/20240125-bump-min-llvm-ver-to-13-0-1-v1-10-f5ff9bda41c5@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: "Aneesh Kumar K.V (IBM)" <aneesh.kumar@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Conor Dooley <conor@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
f785785c |
| 22-Jan-2024 |
Geert Uytterhoeven <geert+renesas@glider.be> |
lib: dhry: add missing closing parenthesis
The help text for the Dhrystone benchmark test lacks a matching closing parenthesis.
Link: https://lkml.kernel.org/r/772b43271bcb3dd17a6aae671b2084f08c05b
lib: dhry: add missing closing parenthesis
The help text for the Dhrystone benchmark test lacks a matching closing parenthesis.
Link: https://lkml.kernel.org/r/772b43271bcb3dd17a6aae671b2084f08c05b079.1705934853.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
1eb1e984 |
| 08-Feb-2024 |
Guenter Roeck <linux@roeck-us.net> |
lib/Kconfig.debug: TEST_IOV_ITER depends on MMU
Trying to run the iov_iter unit test on a nommu system such as the qemu kc705-nommu emulation results in a crash.
KTAP version 1 # Subtest: i
lib/Kconfig.debug: TEST_IOV_ITER depends on MMU
Trying to run the iov_iter unit test on a nommu system such as the qemu kc705-nommu emulation results in a crash.
KTAP version 1 # Subtest: iov_iter # module: kunit_iov_iter 1..9 BUG: failure at mm/nommu.c:318/vmap()! Kernel panic - not syncing: BUG!
The test calls vmap() directly, but vmap() is not supported on nommu systems, causing the crash. TEST_IOV_ITER therefore needs to depend on MMU.
Link: https://lkml.kernel.org/r/20240208153010.1439753-1-linux@roeck-us.net Fixes: 2d71340ff1d4 ("iov_iter: Kunit tests for copying to/from an iterator") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: David Howells <dhowells@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
cd14b018 |
| 11-Feb-2024 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: replace or remove redundant def_bool in Kconfig files
'def_bool X' is a shorthand for 'bool' plus 'default X'.
'def_bool' is redundant where 'bool' is already present, so 'def_bool X' can
treewide: replace or remove redundant def_bool in Kconfig files
'def_bool X' is a shorthand for 'bool' plus 'default X'.
'def_bool' is redundant where 'bool' is already present, so 'def_bool X' can be replaced with 'default X', or removed if X is 'n'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
c4bbe83d |
| 12-Jan-2024 |
Marcos Paulo de Souza <mpdesouza@suse.com> |
livepatch: Move tests from lib/livepatch to selftests/livepatch
The modules are being moved from lib/livepatch to tools/testing/selftests/livepatch/test_modules.
This code moving will allow writing
livepatch: Move tests from lib/livepatch to selftests/livepatch
The modules are being moved from lib/livepatch to tools/testing/selftests/livepatch/test_modules.
This code moving will allow writing more complex tests, like for example an userspace C code that will call a livepatched kernel function.
The modules are now built as out-of-tree modules, but being part of the kernel source means they will be maintained.
Another advantage of the code moving is to be able to easily change, debug and rebuild the tests by running make on the selftests/livepatch directory, which is not currently possible since the modules on lib/livepatch are build and installed using the "modules" target.
The current approach also keeps the ability to execute the tests manually by executing the scripts inside selftests/livepatch directory, as it's currently supported. If the modules are modified, they needed to be rebuilt before running the scripts though.
The modules are built before running the selftests when using the kselftest invocations:
make kselftest TARGETS=livepatch or make -C tools/testing/selftests/livepatch run_tests
Having the modules being built as out-of-modules requires changing the currently used 'modprobe' by 'insmod' and adapt the test scripts that check for the kernel message buffer.
Now it is possible to only compile the modules by running:
make -C tools/testing/selftests/livepatch/
This way the test modules and other test program can be built in order to be packaged if so desired.
As there aren't any modules being built on lib/livepatch, remove the TEST_LIVEPATCH Kconfig and it's references.
Note: "make gen_tar" packages the pre-built binaries into the tarball. It means that it will store the test modules pre-built for the kernel running on the build host.
Note that these modules need not binary compatible with the kernel built from the same sources. But the same is true for other packaged selftest binaries.
The entire kernel sources are needed for rebuilding the selftests on another system.
Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
show more ...
|
#
a4426641 |
| 05-Dec-2023 |
Nathan Chancellor <nathan@kernel.org> |
lib/Kconfig.debug: Update AS_HAS_NON_CONST_LEB128 comment and name
Fangrui noted that the comment around CONFIG_AS_HAS_NON_CONST_LEB128 could be made more accurate because explicit .sleb128 directiv
lib/Kconfig.debug: Update AS_HAS_NON_CONST_LEB128 comment and name
Fangrui noted that the comment around CONFIG_AS_HAS_NON_CONST_LEB128 could be made more accurate because explicit .sleb128 directives are not emitted, only .uleb128 directives are. Rename the symbol to CONFIG_AS_HAS_NON_CONST_ULEB128 as a result.
Further clarifications include replacing "symbol deltas" with the more accurate "label differences", noting that this issue has been resolved in newer binutils (2.41+), and it only occurs when a port uses RISC-V style linker relaxation.
Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20231205-riscv-restrict-dwarf5-llvm-v2-3-aedf00a382ac@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
ae84ff9a |
| 05-Dec-2023 |
Nathan Chancellor <nathan@kernel.org> |
riscv: Restrict DWARF5 when building with LLVM to known working versions
LLVM prior to 18.0.0 would generate incorrect debug info for DWARF5 due to linker relaxation, which was worked around in clan
riscv: Restrict DWARF5 when building with LLVM to known working versions
LLVM prior to 18.0.0 would generate incorrect debug info for DWARF5 due to linker relaxation, which was worked around in clang by defaulting RISC-V to DWARF4 [1]. Unfortunately, this workaround does not work for the kernel because the DWARF version can be independently changed from the default in Kconfig.
Do not allow DWARF5 to be selected for RISC-V when using linker relaxation (ld.lld >= 15.0.0) and a version of LLVM that does not have the fixes (the integrated assembler [2] and ld.lld [3] < 18.0.0) necessary to generate the correct debug info.
Link: https://github.com/llvm/llvm-project/commit/bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6 [1] Link: https://github.com/llvm/llvm-project/commit/1df5ea29b43690b6622db2cad7b745607ca4de6a [2] Link: https://github.com/llvm/llvm-project/commit/7ffabb61a5569444b5ac9322e22e5471cc5e4a77 [3] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Link: https://lore.kernel.org/r/20231205-riscv-restrict-dwarf5-llvm-v2-2-aedf00a382ac@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
aaa2c9a9 |
| 05-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
lib/Kconfig.debug: disable CONFIG_DEBUG_INFO_BTF for Hexagon
pahole, which generates BTF, relies on elfutils to process DWARF debug info. Because kernel modules are relocatable files, elfutils need
lib/Kconfig.debug: disable CONFIG_DEBUG_INFO_BTF for Hexagon
pahole, which generates BTF, relies on elfutils to process DWARF debug info. Because kernel modules are relocatable files, elfutils needs to resolve relocations when processing the DWARF .debug sections.
Hexagon is not supported in binutils or elfutils, so elfutils is unable to process relocations in kernel modules, causing pahole to crash during BTF generation.
Do not allow CONFIG_DEBUG_INFO_BTF to be selected for Hexagon until it is supported in elfutils, so that there are no more cryptic build failures during BTF generation.
Link: https://lkml.kernel.org/r/20240105-hexagon-disable-btf-v1-1-ddab073e7f74@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312192107.wMIKiZWw-lkp@intel.com/ Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Brian Cain <bcain@quicinc.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
bc09d1de |
| 19-Dec-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
lib: add note about process exit message for DEBUG_STACK_USAGE
DEBUG_STACK_USAGE doesn't only have an influence on the output of sysrq-T and sysrq-P, it also enables a message at process exit. See
lib: add note about process exit message for DEBUG_STACK_USAGE
DEBUG_STACK_USAGE doesn't only have an influence on the output of sysrq-T and sysrq-P, it also enables a message at process exit. See check_stack_usage() in kernel/exit.c where this is implemented.
Link: https://lkml.kernel.org/r/20231219182808.210284-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Douglas Anderson <dianders@chromium.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Kees Cook <keescook@chromium.org> Cc: Marco Elver <elver@google.com> Cc: "Paul E. McKenney" <paulmck@kernel.org> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Petr Mladek <pmladek@suse.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Stephen Boyd <sboyd@kernel.org> Cc: Zhaoyang Huang <zhaoyang.huang@unisoc.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
0df52582 |
| 04-Dec-2023 |
Mark Rutland <mark.rutland@arm.com> |
kcov: remove stale RANDOMIZE_BASE text
The Kconfig help text for CONFIG_KCOV describes that recorded PC values will not be stable across machines or reboots when RANDOMIZE_BASE is selected. This wa
kcov: remove stale RANDOMIZE_BASE text
The Kconfig help text for CONFIG_KCOV describes that recorded PC values will not be stable across machines or reboots when RANDOMIZE_BASE is selected. This was the case when KCOV was introduced in commit:
5c9a8750a6409c63 ("kernel: add kcov code coverage")
However, this changed in commit:
4983f0ab7ffaad1e ("kcov: make kcov work properly with KASLR enabled")
Since that commit KCOV always subtracts the KASLR offset from PC values, which ensures that these are stable across machines and across reboots even when RANDOMIZE_BASE is selected.
Unfortunately, that commit failed to update the Kconfig help text, which still suggests disabling RANDOMIZE_BASE even though this is no longer necessary.
Remove the stale Kconfig text.
Link: https://lkml.kernel.org/r/20231204171807.3313022-1-mark.rutland@arm.com Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Cc: Alexander Popov <alex.popov@linux.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
#
ae191417 |
| 15-Dec-2023 |
Jens Axboe <axboe@kernel.dk> |
cred: get rid of CONFIG_DEBUG_CREDENTIALS
This code is rarely (never?) enabled by distros, and it hasn't caught anything in decades. Let's kill off this legacy debug code.
Suggested-by: Linus Torva
cred: get rid of CONFIG_DEBUG_CREDENTIALS
This code is rarely (never?) enabled by distros, and it hasn't caught anything in decades. Let's kill off this legacy debug code.
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
2a19be61 |
| 02-Oct-2023 |
Vlastimil Babka <vbabka@suse.cz> |
mm/slab: remove CONFIG_SLAB from all Kconfig and Makefile
Remove CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_SLAB_DEPRECATED and everything in Kconfig files and mm/Makefile that depends on those. Since S
mm/slab: remove CONFIG_SLAB from all Kconfig and Makefile
Remove CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_SLAB_DEPRECATED and everything in Kconfig files and mm/Makefile that depends on those. Since SLUB is the only remaining allocator, remove the allocator choice, make CONFIG_SLUB a "def_bool y" for now and remove all explicit dependencies on SLUB or SLAB as it's now always enabled. Make every option's verbose name and description refer to "the slab allocator" without refering to the specific implementation. Do not rename the CONFIG_ option names yet.
Everything under #ifdef CONFIG_SLAB, and mm/slab.c is now dead code, all code under #ifdef CONFIG_SLUB is now always compiled.
Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Christoph Lameter <cl@linux.com> Acked-by: David Rientjes <rientjes@google.com> Tested-by: David Rientjes <rientjes@google.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
show more ...
|
#
8c8d2d96 |
| 18-Mar-2017 |
Kent Overstreet <kent.overstreet@gmail.com> |
bcache: move closures to lib/
Prep work for bcachefs - being a fork of bcache it also uses closures
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> Acked-by: Coly Li <colyli@suse.de> Rev
bcache: move closures to lib/
Prep work for bcachefs - being a fork of bcache it also uses closures
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> Acked-by: Coly Li <colyli@suse.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
show more ...
|
#
92f90d3b |
| 17-Oct-2023 |
wuqiang.matt <wuqiang.matt@bytedance.com> |
lib: objpool test module added
The test_objpool module (test_objpool) will run several testcases for objpool stress and performance evaluation. Each testcase will have all available cpu cores involv
lib: objpool test module added
The test_objpool module (test_objpool) will run several testcases for objpool stress and performance evaluation. Each testcase will have all available cpu cores involved to create a situation of high parallel and high contention.
As of now there are 5 groups and 5 * 2 testcases in total:
1) group 1: synchronous mode objpool is managed synchronously, that is, all objects are to be reclaimed before objpool finalization and the objpool owner makes sure of it. All threads on different cores run in the same pace 2) group 2: synchronous mode + hrtimer this case have 2 customers: normal threads and hrtimer softirqs 3) group 3: synchronous + overrun mode This test group is mainly for performance evaluation of missing cases when pre-allocated objects are less than the requested 4) group 4: asynchronous mode This case is just an emulation of kretprobe, with refcount used to control the objpool lifecycle 5) group 5: asynchronous mode with hrtimer hrtimer softirq is introduced to stress async objpool operations
Link: https://lore.kernel.org/all/20231017135654.82270-3-wuqiang.matt@bytedance.com/
Signed-off-by: wuqiang.matt <wuqiang.matt@bytedance.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
show more ...
|
#
cf8e8658 |
| 20-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
arch: Remove Itanium (IA-64) architecture
The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS
arch: Remove Itanium (IA-64) architecture
The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice.
None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago.
While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case.
There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real.
So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed.
[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/
Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
2d71340f |
| 08-Sep-2023 |
David Howells <dhowells@redhat.com> |
iov_iter: Kunit tests for copying to/from an iterator
Add some kunit tests for page extraction for ITER_BVEC, ITER_KVEC and ITER_XARRAY type iterators. ITER_UBUF and ITER_IOVEC aren't dealt with as
iov_iter: Kunit tests for copying to/from an iterator
Add some kunit tests for page extraction for ITER_BVEC, ITER_KVEC and ITER_XARRAY type iterators. ITER_UBUF and ITER_IOVEC aren't dealt with as they require userspace VM interaction. ITER_DISCARD isn't dealt with either as that does nothing.
Signed-off-by: David Howells <dhowells@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Christian Brauner <brauner@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: David Hildenbrand <david@redhat.com> Cc: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
89775a27 |
| 16-Aug-2023 |
Nathan Chancellor <nathan@kernel.org> |
lib/Kconfig.debug: Restrict DEBUG_INFO_SPLIT for RISC-V
When building for ARCH=riscv using LLVM < 14, there is an error with CONFIG_DEBUG_INFO_SPLIT=y:
error: A dwo section may not contain reloca
lib/Kconfig.debug: Restrict DEBUG_INFO_SPLIT for RISC-V
When building for ARCH=riscv using LLVM < 14, there is an error with CONFIG_DEBUG_INFO_SPLIT=y:
error: A dwo section may not contain relocations
This was worked around in LLVM 15 by disallowing '-gsplit-dwarf' with '-mrelax' (the default), so CONFIG_DEBUG_INFO_SPLIT is not selectable with newer versions of LLVM:
$ clang --target=riscv64-linux-gnu -gsplit-dwarf -c -o /dev/null -x c /dev/null clang: error: -gsplit-dwarf is unsupported with RISC-V linker relaxation (-mrelax)
GCC silently had a similar issue that was resolved with GCC 12.x. Restrict CONFIG_DEBUG_INFO_SPLIT for RISC-V when using LLVM or GCC < 12.x to avoid these known issues.
Link: https://github.com/ClangBuiltLinux/linux/issues/1914 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090 Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202308090204.9yZffBWo-lkp@intel.com/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230816-riscv-debug_info_split-v1-1-d1019d6ccc11@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
3ed8513c |
| 27-Jul-2023 |
Jisheng Zhang <jszhang@kernel.org> |
riscv: enable DEBUG_FORCE_FUNCTION_ALIGN_64B
Allow to force all function address 64B aligned as it is possible for other architectures. This may be useful when verify if performance bump is caused b
riscv: enable DEBUG_FORCE_FUNCTION_ALIGN_64B
Allow to force all function address 64B aligned as it is possible for other architectures. This may be useful when verify if performance bump is caused by function alignment changes.
Before commit 1bf18da62106 ("lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option"), riscv supports enabling the DEBUG_FORCE_FUNCTION_ALIGN_64B option, but after that commit, each arch needs to claim the support explicitly.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230727160356.3874-1-jszhang@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
#
aa9f10d5 |
| 11-Aug-2023 |
Marco Elver <elver@google.com> |
hardening: Move BUG_ON_DATA_CORRUPTION to hardening options
BUG_ON_DATA_CORRUPTION is turning detected corruptions of list data structures from WARNings into BUGs. This can be useful to stop further
hardening: Move BUG_ON_DATA_CORRUPTION to hardening options
BUG_ON_DATA_CORRUPTION is turning detected corruptions of list data structures from WARNings into BUGs. This can be useful to stop further corruptions or even exploitation attempts.
However, the option has less to do with debugging than with hardening. With the introduction of LIST_HARDENED, it makes more sense to move it to the hardening options, where it selects LIST_HARDENED instead.
Without this change, combining BUG_ON_DATA_CORRUPTION with LIST_HARDENED alone wouldn't be possible, because DEBUG_LIST would always be selected by BUG_ON_DATA_CORRUPTION.
Signed-off-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20230811151847.1594958-4-elver@google.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|