linux-kernel - Re: tracer_init

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] [day] [month] [year] [list]

Message-ID: <20201209111738.73944eac@gandalf.local.home>
Date:   Wed, 9 Dec 2020 11:17:38 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Lucas Stach <l.stach@...gutronix.de>
Cc:     Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: tracer_init_tracefs really slow

On Wed, 09 Dec 2020 15:38:50 +0100
Lucas Stach <l.stach@...gutronix.de> wrote:

> -	trace_eval_init();
> -
> ... and this. Moving the trace_eval_init into its own initcall means it
> gets started before tracer_init_tracefs. As it holds the
> trace_event_sem while updating the eval maps, event_trace_init() then
> blocks further initcall execution when it tries to grab this semaphore
> a bit down the line, killing the parallelism we are trying to unlock
> here.
> 
> With those 2 lines dropped, the change seems to work as intended and
> shaves ~830ms from the kernel boot time on this system.

Ah, the rationale to do that was so that it could start parsing earlier.
But you are right, if it's really slow, and is still parsing by the time we
start populating the tracefs directory, it will then cause that to block as
well.

OK, I wont move it into its own initcall and send a v2.

-- Steve