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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 2 Nov 2021 13:20:48 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] printk's sync mode for ftrace_dump()

On 2021-10-29 13:18:33 [+0206], John Ogness wrote:
> On 2021-10-29, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> > ftrace_dump() is used for instance by alt-sysrq-z / sysrq_ftrace_dump().
> > The function itself dumps the whole trace buffer in an irq-off section so
> > no need to talk about max latencies unless this is going to change.
> >
> > The output on the serial is more or less brief and starts with
> >     "** 397774 printk messages dropped **"
> > and so I do see only the end of it. Might be okay.
> > Any reason not to use the sync mode + atomic console while ftrace_dump()
> > is in progress?
> 
> Since latencies are not a concern, I see no reason not to use
> sync+atomic.
> 
> However, it does put us into the situation of beginning to define
> non-emergency scenarios where sync+atomic is used. That rabbit hole
> might go quite deep. I wonder if it might be better to introduce a new
> sysrq to toggle sync mode.

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?

As per rabbit hole, I'm bringing my case to the high council.
I wouldn't mind if using the sync-mode would taint the kernel..

> John

Sebastian