linux-kernel - Re: [RFC V2 12/21] rv/reactor: Add the printk reactor

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: <874k50hqmj.fsf@jogness.linutronix.de>
Date:   Tue, 15 Feb 2022 20:39:08 +0106
From:   John Ogness <john.ogness@...utronix.de>
To:     Daniel Bristot de Oliveira <bristot@...nel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>
Cc:     Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Marco Elver <elver@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Gabriele Paoloni <gpaoloni@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Clark Williams <williams@...hat.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-trace-devel@...r.kernel.org
Subject: Re: [RFC V2 12/21] rv/reactor: Add the printk reactor

On 2022-02-15, Daniel Bristot de Oliveira <bristot@...nel.org> wrote:
> I am aware of printk_deferred(), and every once and while I am Cc'ed
> on patches suggesting changing printk() to printk_deferred(), but they
> are not, let's say, welcome [1]... that is why I am not using it.

Yes. printk_deferred() is a workaround until we can get printk
"PROVE_RAW_LOCK_NESTING clean". But currently there is real deadlock
potential in the kernel with printk. For the most common cases, we use
printk_deferred() to get around it. Once printk() is clean, we can
replace all printk_deferred() call sites with printk().

I haven't looked into the details of your runtime verification method,
but I assume it digs deep into some interfaces. In that case, the
deadlock potential of printk may be relatively high. (And indeed, you
have seen some.) IMHO, before warning users not to use this reactor if
locks XYZ are taken, it would be better just to use printk_deferred()
and it will always log without causing problems to the system you are
trying to verify.

> I saw deadlocks in the past, and while testing the WIP monitor some
> time ago, it seems it depends on the console type. If such restriction
> does not exist anymore, I can remove that comment, it would be even
> better!

If you say it depended on the console type, then it was probably the
framebuffer console that was at fault. The fbcon is a landmine for
deadlocks, which is why PREEMPT_RT avoids fbcon printing from
non-preemptible context. For mainline, the series is currently in
review.

Perhaps avoiding fbcon would be good enough for you to avoid deadlocks
with this reactor using printk().

John

> [1]  https://lore.kernel.org/lkml/e68888438cec9a1da53aaa1647720ade638d6ad4.1600705105.git.bristot@redhat.com/