linux-kernel - Re: [PATCH v8] scripts: ftrace - move the sort-processing in ftrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Jan 2022 11:42:28 +0100
From:   Heiko Carstens <hca@...ux.ibm.com>
To:     Sven Schnelle <svens@...ux.ibm.com>
Cc:     Yinan Liu <yinan@...ux.alibaba.com>, rostedt@...dmis.org,
        peterz@...radead.org, mark-pk.tsai@...iatek.com, mingo@...hat.com,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v8] scripts: ftrace - move the sort-processing in
 ftrace_init

On Fri, Jan 21, 2022 at 10:46:36AM +0100, Sven Schnelle wrote:
> Hi Yinan,
> 
> Yinan Liu <yinan@...ux.alibaba.com> writes:
> 
> > 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.
> >
> > Signed-off-by: Yinan Liu <yinan@...ux.alibaba.com>
> > Reported-by: kernel test robot <lkp@...el.com>
> > Reported-by: kernel test robot <oliver.sang@...el.com>
> > ---
> >  kernel/trace/ftrace.c   |  11 +++-
> >  scripts/Makefile        |   6 +-
> >  scripts/link-vmlinux.sh |   6 +-
> >  scripts/sorttable.c     |   2 +
> >  scripts/sorttable.h     | 120 +++++++++++++++++++++++++++++++++++++++-
> >  5 files changed, 137 insertions(+), 8 deletions(-)
> 
> while i like the idea, this unfortunately breaks ftrace on s390. The
> reason for that is that the compiler generates relocation entries for
> all the addresses in __mcount_loc. During boot, the s390 decompressor
> iterates through all the relocations and overwrites the nicely
> sorted list between __start_mcount_loc and __stop_mcount_loc with
> the unsorted list because the relocations entries are not adjusted.
> 
> Of course we could just disable that option, but that would make us
> different compared to x86 which i don't like. Adding code to sort the
> relocation would of course also fix that, but i don't think it is a good
> idea to rely on the order of relocations.
> 
> Any thoughts how a fix could look like, and whether that could also be a
> problem on other architectures?

Sven, thanks for figuring this out. Can you confirm that reverting
commit 72b3942a173c ("scripts: ftrace - move the sort-processing in
ftrace_init") fixes the problem?

This really should be addressed before rc1 is out, otherwise s390 is
broken if somebody enables ftrace.
Where "broken" translates to random crashes as soon as ftrace is
enabled, which again is nowadays quite common.