linux-kernel - Re: [RFC] printk's sync mode for 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] [day] [month] [year] [list]

Message-ID: <20211102084502.5c5a7580@gandalf.local.home>
Date:   Tue, 2 Nov 2021 08:45:02 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     John Ogness <john.ogness@...utronix.de>,
        linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] printk's sync mode for ftrace_dump()

On Tue, 2 Nov 2021 13:20:48 +0100
Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:

> This can be triggered not only by sysrq. panic-on-oops seems to do the
> right thing. It seems that it makes sense to have this sync-mode always
> while ftrace_dump() is running.
> But then any sysrq-request has this limitation so maybe any sysrq should
> force sync-mode. But the sysrq request itself could be redirected into
> printing thread unless the system has some kind of scheduling problem.
> The printing request may not disable interrupts for the whole time as it
> is the case with the trace buffer so it would be possible to wait until
> printing is done if done from the printing thread.
> An additional sysrq to trigger the sync mode seems to be problematic
> because people might not be aware of it. Also, what is it point of
> sysrq-t if you see the last few entries?

Looking at ftrace_dump(), I'm not sure we need interrupts disabled. I think
that was there because it was created for panic only, but today I believe
the ring buffer is more robust, and it does disable everything before
reading the ring buffer. We may want to add some logic to make sure the
user doesn't re-enable tracing while the dump is happening. Or maybe we
don't care. If the user wants the dump to never end, let them re-enable it
;-)

I can write a patch to remove the irq disabling, or at least (to be on the
safe side) to enable it before entering the loop.

-- Steve