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

Message-ID: <20201207114711.0748b19c@gandalf.local.home>
Date:   Mon, 7 Dec 2020 11:47:11 -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 Mon, 07 Dec 2020 17:24:58 +0100
Lucas Stach <l.stach@...gutronix.de> wrote:

> > We could make a thread that does this, that the init wakes up and runs,
> > letting the kernel to move forward. Would you like to make that patch
> > or shall I?  
> 
> I guess you are much more likely to come up with a correct patch, as
> I'm not really clear yet on when we would need to synchronize this
> thread, to make sure things are available before they get used by
> something. I likely won't have time in the near future to read enough
> code in this particular spot of the kernel.

No problem. I've just been told to try to delegate when I can ;-)

> 
> I would be happy to test a patch on our whimpy machines, though. :)

The code is only needed for user space, and we can make it a separate
thread to do the work to let kernel move forward. The code is wrapped with
a mutex so that even if it's still processing when user space is up and
running, and it tries to access the code, it should block until it's
finished as well.

I'll write something up and send it to you.

Thanks for the report!

-- Steve