Commit Graph

5 Commits

Author SHA1 Message Date
Vitaly Kuznetsov a2cf11c056 x86,objtool: Split UNWIND_HINT_EMPTY in two
JIRA: https://issues.redhat.com/browse/RHEL-52683

commit fb799447ae2974a07907906dff5bd4b9e47b7123
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Wed Mar 1 07:13:12 2023 -0800

    x86,objtool: Split UNWIND_HINT_EMPTY in two

    Mark reported that the ORC unwinder incorrectly marks an unwind as
    reliable when the unwind terminates prematurely in the dark corners of
    return_to_handler() due to lack of information about the next frame.

    The problem is UNWIND_HINT_EMPTY is used in two different situations:

      1) The end of the kernel stack unwind before hitting user entry, boot
         code, or fork entry

      2) A blind spot in ORC coverage where the unwinder has to bail due to
         lack of information about the next frame

    The ORC unwinder has no way to tell the difference between the two.
    When it encounters an undefined stack state with 'end=1', it blindly
    marks the stack reliable, which can break the livepatch consistency
    model.

    Fix it by splitting UNWIND_HINT_EMPTY into UNWIND_HINT_UNDEFINED and
    UNWIND_HINT_END_OF_STACK.

    Reported-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/fd6212c8b450d3564b855e1cb48404d6277b4d9f.1677683419.git.jpoimboe@kernel.org

Conflicts:
	arch/x86/entry/entry_64.S (context, skipping f71e1d2ff8e6a)
	arch/x86/kernel/head_64.S (context, skipping 666e1156b2c51)

RHEL-only:
	arch/x86/entry/entry.S: UNWIND_HINT_EMPTY->UNWIND_HINT_UNDEFINED to
        match upstream.

Omitted-fix: b9f174c811e3 ("x86/unwind/orc: Add ELF section with ORC version identifier")
 see https://issues.redhat.com/browse/RHEL-27234 for discussion

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
2024-09-18 15:14:40 +02:00
Donald Dutile ed57f2e361 script/sorttable: Fix some initialization problems
JIRA: https://issues.redhat.com/browse/RHEL-28063

commit 35140d399db2b67153fc53b51a97ddb8ba3b5956
Author: Yinan Liu <yinan@linux.alibaba.com>
Date:   Tue Jan 18 14:52:41 2022 +0800

    script/sorttable: Fix some initialization problems

    elf_mcount_loc and mcount_sort_thread definitions are not
    initialized immediately within the function, which can cause
    the judgment logic to use uninitialized values when the
    initialization logic of subsequent code fails.

    Link: https://lkml.kernel.org/r/20211212113358.34208-2-yinan@linux.alibaba.com
    Link: https://lkml.kernel.org/r/20220118065241.42364-1-yinan@linux.alibaba.com

    Fixes: 72b3942a173c ("scripts: ftrace - move the sort-processing in ftrace_init")
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Yinan Liu <yinan@linux.alibaba.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Signed-off-by: Donald Dutile <ddutile@redhat.com>
2024-06-17 14:17:12 -04:00
Donald Dutile 1c7ced2303 scripts: ftrace - move the sort-processing in ftrace_init
JIRA: https://issues.redhat.com/browse/RHEL-28063

commit 72b3942a173c387b27860ba1069636726e208777
Author: Yinan Liu <yinan@linux.alibaba.com>
Date:   Sun Dec 12 19:33:58 2021 +0800

    scripts: ftrace - move the sort-processing in ftrace_init

    When the kernel starts, the initialization of ftrace takes
    up a portion of the time (approximately 6~8ms) to sort mcount
    addresses. We can save this time by moving mcount-sorting to
    compile time.

    Link: https://lkml.kernel.org/r/20211212113358.34208-2-yinan@linux.alibaba.com

    Signed-off-by: Yinan Liu <yinan@linux.alibaba.com>
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Signed-off-by: Donald Dutile <ddutile@redhat.com>
2024-06-17 14:17:12 -04:00
Shile Zhang 57fa189942 scripts/sorttable: Implement build-time ORC unwind table sorting
The ORC unwinder has two tables: .orc_unwind_ip and .orc_unwind, which
need to be sorted for binary search. Previously this sorting was done
during bootup.

Sort them at build time to speed up booting.

Add the ORC tables sorting in a parallel build process to speed up the build.

[ mingo: Rewrote the changelog and fixed some comments. ]

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-7-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-13 10:47:58 +01:00
Shile Zhang 1091670637 scripts/sorttable: Rename 'sortextable' to 'sorttable'
Use a more generic name for additional table sorting usecases,
such as the upcoming ORC table sorting feature. This tool is
not tied to exception table sorting anymore.

No functional changes intended.

[ mingo: Rewrote the changelog. ]

Signed-off-by: Shile Zhang <shile.zhang@linux.alibaba.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Link: https://lkml.kernel.org/r/20191204004633.88660-6-shile.zhang@linux.alibaba.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-13 10:47:58 +01:00