Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   John Ogness <john.ogness@linutronix.de>
To:     Daniel Bristot de Oliveira <bristot@kernel.org>,
        Shuah Khan <skhan@linuxfoundation.org>,
        Steven Rostedt <rostedt@goodmis.org>
Cc:     Jonathan Corbet <corbet@lwn.net>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Marco Elver <elver@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Gabriele Paoloni <gpaoloni@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Clark Williams <williams@redhat.com>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-trace-devel@vger.kernel.org
Subject: Re: [RFC V2 12/21] rv/reactor: Add the printk reactor
In-Reply-To: <65172f14-bad6-37b1-d243-e91ca472d22e@kernel.org>
References: <cover.1644830251.git.bristot@kernel.org>
 <fad2d358d57dfffc084d482684ecc1d13b62b262.1644830251.git.bristot@kernel.org>
 <10cf6003-6d2b-056b-11bb-3ae9c342a369@linuxfoundation.org>
 <c1657d1c-0d2b-4aa3-c1ed-2ae6fdfcda86@kernel.org>
 <87v8xg30qc.fsf@jogness.linutronix.de>
 <45179cdb-2391-207a-2f7b-2dea828d1606@kernel.org>
 <87r1842r1m.fsf@jogness.linutronix.de>
 <65172f14-bad6-37b1-d243-e91ca472d22e@kernel.org>
Date:   Tue, 15 Feb 2022 20:39:08 +0106
Message-ID: <874k50hqmj.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 2022-02-15, Daniel Bristot de Oliveira <bristot@kernel.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/