x86/smp: Fix mwait_play_dead() and acpi_processor_ffh_play_dead() noreturn behavior

Fix some related issues (done in a single patch to avoid introducing
intermediate bisect warnings):

1) The SMP

x86/smp: Fix mwait_play_dead() and acpi_processor_ffh_play_dead() noreturn behavior

Fix some related issues (done in a single patch to avoid introducing
intermediate bisect warnings):

1) The SMP version of mwait_play_dead() doesn't return, but its
!SMP counterpart does. Make its calling behavior consistent by
resolving the !SMP version to a BUG(). It should never be called
anyway, this just enforces that at runtime and enables its callers
to be marked as __noreturn.

2) While the SMP definition of mwait_play_dead() is annotated as
__noreturn, the declaration isn't. Nor is it listed in
tools/objtool/noreturns.h. Fix that.

3) Similar to #1, the SMP version of acpi_processor_ffh_play_dead()
doesn't return but its !SMP counterpart does. Make the !SMP
version a BUG(). It should never be called.

4) acpi_processor_ffh_play_dead() doesn't return, but is lacking any
__noreturn annotations. Fix that.

This fixes the following objtool warnings:

vmlinux.o: warning: objtool: acpi_processor_ffh_play_dead+0x67: mwait_play_dead() is missing a __noreturn annotation
vmlinux.o: warning: objtool: acpi_idle_play_dead+0x3c: acpi_processor_ffh_play_dead() is missing a __noreturn annotation

Fixes: a7dd183f0b38 ("x86/smp: Allow calling mwait_play_dead with an arbitrary hint")
Fixes: 541ddf31e300 ("ACPI/processor_idle: Add FFH state handling")
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Paul E. McKenney <[email protected]>
Link: https://lore.kernel.org/r/e885c6fa9e96a61471b33e48c2162d28b15b14c5.1740962711.git.jpoimboe@kernel.org

show more ...

objtool: Add bch2_trans_unlocked_or_in_restart_error() to bcachefs noreturns

Fix the following objtool warning during build time:

fs/bcachefs/btree_cache.o: warning: objtool: btree_node_lock.cons

objtool: Add bch2_trans_unlocked_or_in_restart_error() to bcachefs noreturns

Fix the following objtool warning during build time:

fs/bcachefs/btree_cache.o: warning: objtool: btree_node_lock.constprop.0() falls through to next function bch2_recalc_btree_reserve()
fs/bcachefs/btree_update.o: warning: objtool: bch2_trans_update_get_key_cache() falls through to next function need_whiteout_for_snapshot()

bch2_trans_unlocked_or_in_restart_error() is an Obviously Correct (tm)
panic() wrapper, add it to the list of known noreturns.

Fixes: b318882022a8 ("bcachefs: bch2_trans_verify_not_unlocked_or_in_restart()")
Reported-by: k2ci <[email protected]>
Signed-off-by: Youling Tang <[email protected]>
Reviewed-by: Kent Overstreet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

objtool: Add bch2_trans_unlocked_error() to bcachefs noreturns

Fix the following objtool warning during build time:

fs/bcachefs/btree_trans_commit.o: warning: objtool: bch2_trans_commit_write_l

objtool: Add bch2_trans_unlocked_error() to bcachefs noreturns

Fix the following objtool warning during build time:

fs/bcachefs/btree_trans_commit.o: warning: objtool: bch2_trans_commit_write_locked.isra.0() falls through to next function do_bch2_trans_commit.isra.0()
fs/bcachefs/btree_trans_commit.o: warning: objtool: .text: unexpected end of section
......
fs/bcachefs/btree_update.o: warning: objtool: bch2_trans_update_get_key_cache() falls through to next function flush_new_cached_update()
fs/bcachefs/btree_update.o: warning: objtool: flush_new_cached_update() falls through to next function bch2_trans_update_by_path()

bch2_trans_unlocked_error() is an Obviously Correct (tm) panic() wrapper,
add it to the list of known noreturns.

[ mingo: Improved the changelog ]

Fixes: fd104e2967b7 ("bcachefs: bch2_trans_verify_not_unlocked()")
Signed-off-by: chenchangcheng <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]

show more ...

reiserfs: The last commit

Deprecation period of reiserfs ends with the end of this year so it is
time to remove it from the kernel.

Acked-by: Darrick J. Wong <[email protected]>
Acked-by: Christian

reiserfs: The last commit

Deprecation period of reiserfs ends with the end of this year so it is
time to remove it from the kernel.

Acked-by: Darrick J. Wong <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Signed-off-by: Jan Kara <[email protected]>

show more ...

objtool/rust: list `noreturn` Rust functions

Rust functions may be `noreturn` (i.e. diverging) by returning the
"never" type, `!`, e.g.

fn f() -> ! {
loop {}
}

Thus list the known

objtool/rust: list `noreturn` Rust functions

Rust functions may be `noreturn` (i.e. diverging) by returning the
"never" type, `!`, e.g.

fn f() -> ! {
loop {}
}

Thus list the known `noreturn` functions to avoid such warnings.

Without this, `objtool` would complain if enabled for Rust, e.g.:

rust/core.o: warning: objtool:
_R...9panic_fmt() falls through to next function _R...18panic_nounwind_fmt()

rust/alloc.o: warning: objtool:
.text: unexpected end of section

In order to do so, we cannot match symbols' names exactly, for two
reasons:

- Rust mangling scheme [1] contains disambiguators [2] which we
cannot predict (e.g. they may vary depending on the compiler version).

One possibility to solve this would be to parse v0 and ignore/zero
those before comparison.

- Some of the diverging functions come from `core`, i.e. the Rust
standard library, which may change with each compiler version
since they are implementation details (e.g. `panic_internals`).

Thus, to workaround both issues, only part of the symbols are matched,
instead of using the `NORETURN` macro in `noreturns.h`.

Ideally, just like for the C side, we should have a better solution. For
instance, the compiler could give us the list via something like:

$ rustc --emit=noreturns ...

[ Kees agrees this should be automated and Peter says:

So it would be fairly simple to make objtool consume a magic section
emitted by the compiler.. I think we've asked the compiler folks
for that at some point even, but I don't have clear recollections.

We will ask upstream Rust about it. And if they agree, then perhaps
we can get Clang/GCC to implement something similar too -- for this
sort of thing we can take advantage of the shorter cycles of `rustc`
as well as their unstable features concept to experiment.

Gary proposed using DWARF (though it would need to be available), and
wrote a proof of concept script using the `object` and `gimli` crates:
https://gist.github.com/nbdd0121/449692570622c2f46a29ad9f47c3379a

- Miguel ]

Link: https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html [1]
Link: https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#disambiguator [2]
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Tested-by: Benno Lossin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `len_mismatch_fail` symbol for new `kernel` crate code merged
since then as well as 3 more `core::panicking` symbols that appear
in `RUST_DEBUG_ASSERTIONS=y` builds. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

x86/syscall: Mark exit[_group] syscall handlers __noreturn

The direct-call syscall dispatch function doesn't know that the exit()
and exit_group() syscall handlers don't return, so the call sites ar

x86/syscall: Mark exit[_group] syscall handlers __noreturn

The direct-call syscall dispatch function doesn't know that the exit()
and exit_group() syscall handlers don't return, so the call sites aren't
optimized accordingly.

Fix that by marking the exit syscall declarations __noreturn.

Fixes the following warnings:

vmlinux.o: warning: objtool: x64_sys_call+0x2804: __x64_sys_exit() is missing a __noreturn annotation
vmlinux.o: warning: objtool: ia32_sys_call+0x29b6: __ia32_sys_exit_group() is missing a __noreturn annotation

Fixes: 1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system calls")
Closes: https://lkml.kernel.org/lkml/6dba9b32-db2c-4e6d-9500-7a08852f17a3@paulmck-laptop
Reported-by: Paul E. McKenney <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Tested-by: Paul E. McKenney <[email protected]>
Link: https://lore.kernel.org/r/5d8882bc077d8eadcc7fd1740b56dfb781f12288.1719381528.git.jpoimboe@kernel.org

show more ...

fortify: Split reporting and avoid passing string pointer

In preparation for KUnit testing and further improvements in fortify
failure reporting, split out the report and encode the function and acc

fortify: Split reporting and avoid passing string pointer

In preparation for KUnit testing and further improvements in fortify
failure reporting, split out the report and encode the function and access
failure (read or write overflow) into a single u8 argument. This mainly
ends up saving a tiny bit of space in the data segment. For a defconfig
with FORTIFY_SOURCE enabled:

$ size gcc/vmlinux.before gcc/vmlinux.after
text data bss dec hex filename
26132309 9760658 2195460 38088427 2452eeb gcc/vmlinux.before
26132386 9748382 2195460 38076228 244ff44 gcc/vmlinux.after

Reviewed-by: Alexander Lobakin <[email protected]>
Signed-off-by: Kees Cook <[email protected]>

show more ...

init: remove obsolete arch_call_rest_init() wrapper

Since commit 3570ee046c46b5dc ("s390/smp: keep the original lowcore for
CPU 0"), there is no longer any architecture that needs to override
arch_c

init: remove obsolete arch_call_rest_init() wrapper

Since commit 3570ee046c46b5dc ("s390/smp: keep the original lowcore for
CPU 0"), there is no longer any architecture that needs to override
arch_call_rest_init().

Remove the weak wrapper around rest_init(), call rest_init() directly, and
make rest_init() static.

Link: https://lkml.kernel.org/r/aa10868bfb176eef4abb8bb4a710b85330792694.1706106183.git.geert@linux-m68k.org
Signed-off-by: Geert Uytterhoeven <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Ilya Leoshkevich <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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 <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

objtool: Add bcachefs noreturns

Signed-off-by: Kent Overstreet <[email protected]>

x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed()

LKP reported below build warning:

vmlinux.o: warning: objtool: __tdx_hypercall+0x128: __tdx_hypercall_failed() is missing a _

x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed()

LKP reported below build warning:

vmlinux.o: warning: objtool: __tdx_hypercall+0x128: __tdx_hypercall_failed() is missing a __noreturn annotation

The __tdx_hypercall_failed() function definition already has __noreturn
annotation, but it turns out the __noreturn must be annotated to the
function declaration.

PeterZ explains:

"FWIW, the reason being that...

The point of noreturn is that the caller should know to stop generating
code. For that the declaration needs the attribute, because call sites
typically do not have access to the function definition in C."

Add __noreturn annotation to the declaration of __tdx_hypercall_failed()
to fix. It's not a bad idea to document the __noreturn nature at the
definition site either, so keep the annotation at the definition.

Note <asm/shared/tdx.h> is also included by TDX related assembly files.
Include <linux/compiler_attributes.h> only in case of !__ASSEMBLY__
otherwise compiling assembly file would trigger build error.

Also, following the objtool documentation, add __tdx_hypercall_failed()
to "tools/objtool/noreturns.h".

Fixes: c641cfb5c157 ("x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE_CALL")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Kai Huang <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

show more ...

objtool: Remove btrfs_assertfail() from the noreturn exceptions list

The objtool merge in commit 6f612579be9d ("Merge tag 'objtool-core ...")
generated a semantic conflict that was not resolved.

Th

objtool: Remove btrfs_assertfail() from the noreturn exceptions list

The objtool merge in commit 6f612579be9d ("Merge tag 'objtool-core ...")
generated a semantic conflict that was not resolved.

The btrfs_assertfail() entry was removed from the noreturn list in
commit b831306b3b7d ("btrfs: print assertion failure report and stack
trace from the same line") because btrfs_assertfail() was changed from a
noreturn function into a macro.

The noreturn list was then moved from check.c to noreturns.h in commit
6245ce4ab670 ("objtool: Move noreturn function list to separate file"),
and should be removed from that post-merge as well.

Do it explicitly.

Cc: David Sterba <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

objtool: Add __kunit_abort() to noreturns

Fixes a bunch of warnings like:

drivers/input/tests/input_test.o: warning: objtool: input_test_init+0x1cb: stack state mismatch: cfa1=4+64 cfa2=4+56
li

objtool: Add __kunit_abort() to noreturns

Fixes a bunch of warnings like:

drivers/input/tests/input_test.o: warning: objtool: input_test_init+0x1cb: stack state mismatch: cfa1=4+64 cfa2=4+56
lib/kunit/kunit-test.o: warning: objtool: kunit_log_newline_test+0xfb: return with modified stack frame
...

Fixes: 260755184cbd ("kunit: Move kunit_abort() call out of kunit_do_failed_assertion()")
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lkml.kernel.org/r/20230602175453.swsn3ehyochtwkhy@treble

show more ...

objtool: Move noreturn function list to separate file

This makes it a little cleaner and easier to maintain.

Suggested-by: Peter Zijlstra <[email protected]>
Reviewed-by: Miroslav Benes <mbenes@

objtool: Move noreturn function list to separate file

This makes it a little cleaner and easier to maintain.

Suggested-by: Peter Zijlstra <[email protected]>
Reviewed-by: Miroslav Benes <[email protected]>
Link: https://lore.kernel.org/r/cecacf07a69a244c74474c18b7652627de67a528.1681853186.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...