linux-kernel - Re: [RFC 2/2] printk: Add more information about the printk caller

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: <87k0wj7fcs.fsf@jogness.linutronix.de>
Date:   Thu, 24 Sep 2020 10:29:31 +0206
From:   John Ogness <john.ogness@...utronix.de>
To:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Prarit Bhargava <prarit@...hat.com>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        Orson Zhai <orsonzhai@...il.com>,
        Changki Kim <changki.kim@...sung.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/2] printk: Add more information about the printk caller

On 2020-09-24, Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote:
> A question. Suppose we have a task which does
>
> 	CPU0
>
> 	pr_err(...);
>
> 	preempt_disable();
> 	pr_err(...);
> 	preempt_enable();
>
> 	pr_err(...);
>
> 	rcu_read_lock();
> 	pr_info(...);
> 	rcu_read_unlock();
>
> Should we distinguish those as 3 different contexts?
>
> - normal printk
> - printk under disabled preemption (affects scheduling)
> - printk under RCU read side lock (affects RCU grace periods)

The internal purpose of the printk_info's @caller_id is to support
_some_ sanity with LOG_CONT. True LOG_CONT sanity will not be available
until we provide a context API like we previously talked about [0]. But
for now it is good enough (even if it is not good).

We can also store various flags and counters to describe the current
context. But these would only exist to provide the user with information
rather than because printk itself needs it. I only mention this so that
we don't get things mixed up. We can add as much information as want,
but LOG_CONT will only be interested in a subset of that.

John Ogness