linux-kernel - Re: [PATCH] printk/tracing: Do not trace printk_nmi

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:   Fri, 7 Sep 2018 09:47:03 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH] printk/tracing: Do not trace printk_nmi_enter()

On Fri, 7 Sep 2018 17:35:38 +0900
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com> wrote:

> Should't printk_nmi_enter()/printk_nmi_exit() still be notrace?
> Like you and Steven said - it's still before ftrace_nmi_enter()
> and should be notrace regardless.

Correct. My patch fixes both issues.

The patch that Peter is posting is in case for some reason in the future
printk_nmi_enter/exit() do something with interrupts or locking.

And the printk_nmi_enter/exit() is placed where it is, in case for some
reason lockdep_off/on() does a printk.

The printk_nmi_enter/exit() and lockdep_off/on() are only changing
state variables. Neither of them should be traced by ftrace.

My patch solved the problem and was not just fixing a symptom.

It could have been solved either way, but as Petr said, the
printk_nmi_enter/exit() should have been notrace, because it was before
ftrace_nmi_enter/exit(). Lockdep actually found this bug because the
lockdep_on/off() was not first.

-- Steve