linux-kernel - Re: [PATCH 1/2] 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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 25 Oct 2021 21:20:47 +0800
From:   Yinan Liu <yinan@...ux.alibaba.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     mark-pk.tsai@...iatek.com, peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] scripts: ftrace - move the sort-processing in
 ftrace_init to compile time

On 2021/10/9 上午10:56, Yinan Liu wrote:

>> Probably just keep the sorting algorithm in the kernel and take place
>> on module load.
>>
>> If you still want to sort at compile time, then do the sort for .init
>> functions separate from the .text ones, and have a way to extract this
>> information (shouldn't be too hard) in the kernel at module load, and
>> then just swap the init and text functions if they were added in the
>> reverse order that was expect.
>>
>> The functions in .init will either be before all the functions in .text
>> or after. They wont be intermingled. Thus, if they are both sorted,
>> then they are placed correctly or the two groups of functions need to
>> be switched. No other sorting should be necessary.
>>

Hi, Steven

I try to apply for memory during the relocation phase to separate and 
adjust the mcount of .init.text and .text. After processing, I found 
that the mcount redirection in .ko is based on ".text", ".init.text", 
".ref.text", ".sched.text", ".spinlock.text", ".irqentry .text", 
".softirqentry.text", ".kprobes.text", ".cpuidle.text", 
".text.unlikely", which makes the sorting process at compile time 
cumbersome and inefficient. And .ko is inserted after the kernel start， 
to a certain extent, the optimization meaning of this part is relatively 
small. Now I think it makes more sense to optimize mcount during the 
startup period, because these mcounts based on different section 
redirects are relatively orderly
just like 11, 13, 15, 17, 19, 1, 3, 5, 7, 9, 21, 23, 25, 27, 29
.

At present, it seems that the processing of compile-time sorting is only 
suitable for vmlinux but not suitable for modules. Please review the 
code of mcount sorting in vmlinux, thank you.

> Best regards!
> -- Yinan liu