Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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: <c1657d1c-0d2b-4aa3-c1ed-2ae6fdfcda86@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>
Date:   Tue, 15 Feb 2022 11:09:55 +0106
Message-ID: <87v8xg30qc.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 2022-02-14, Daniel Bristot de Oliveira <bristot@kernel.org> wrote:
> On 2/14/22 18:25, Shuah Khan wrote:
>> On=C2=A02/14/22=C2=A03:45=C2=A0AM,=C2=A0Daniel=C2=A0Bristot=C2=A0de=C2=
=A0Oliveira=C2=A0wrote:
>>> Note:=C2=A0do=C2=A0not=C2=A0use=C2=A0this=C2=A0reactor=C2=A0with=C2=A0r=
q_lock=C2=A0taken,=C2=A0it=C2=A0will=C2=A0lock=C2=A0the
>>> system=C2=A0until=C2=A0printk=C2=A0can=C2=A0handle=C2=A0that.
>>=20
>> Please=C2=A0give=C2=A0more=C2=A0details=C2=A0on=C2=A0"lock=C2=A0the=C2=
=A0system"=C2=A0and=C2=A0how=C2=A0locking
>> would=C2=A0impact=C2=A0users=C2=A0and=C2=A0system=C2=A0operation
>
> It is a deadlock on the rq_lock. Hopefully the new printk
> implementation handles that better.

I suggest using printk_deferred() for this reactor for now. With
printk_deferred() the message and timestamp are immediately and
locklessly stored in the buffer, and the printing is performed in a
separate context. printk_deferred() is safe for all contexts.

John