From: Daniel Vetter <daniel@ffwll.ch>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org, Ben Segall <bsegall@google.com>,
Sultan Alsawaf <sultan@kerneltoast.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Anton Vorontsov <anton@enomsg.org>,
Ingo Molnar <mingo@redhat.com>, Mel Gorman <mgorman@suse.de>,
Petr Mladek <pmladek@suse.com>, Kees Cook <keescook@chromium.org>,
John Ogness <john.ogness@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Tony Luck <tony.luck@intel.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Colin Cross <ccross@android.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: printk deadlock due to double lock attempt on current CPU's runqueue
Date: Wed, 10 Nov 2021 14:21:31 +0100 [thread overview]
Message-ID: <YYvHW1OpN1L2uInb@phenom.ffwll.local> (raw)
In-Reply-To: <YYuq5d7MYL2wxlOd@hirez.programming.kicks-ass.net>
On Wed, Nov 10, 2021 at 12:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 10, 2021 at 11:50:38AM +0100, Petr Mladek wrote:
> > On Tue 2021-11-09 12:06:48, Sultan Alsawaf wrote:
> > > Hi,
> > >
> > > I encountered a printk deadlock on 5.13 which appears to still affect the latest
> > > kernel. The deadlock occurs due to printk being used while having the current
> > > CPU's runqueue locked, and the underlying framebuffer console attempting to lock
> > > the same runqueue when printk tries to flush the log buffer.
> > >
> > > I'm not sure what the *correct* solution is here (don't use printk while having
> > > a runqueue locked? don't use schedule_work() from the fbcon path? tell printk
> > > to use one of its lock-less backends?), so I've cc'd all the relevant folks.
> >
> > At the moment, printk_deferred() could be used here. It defers the
> > console handling via irq_work().
>
> I think I've rejected that patch at least twice now :-) John's printk
> stuff will really land real soon now, right.
Yeah whacking all affected prinkt callers just because of fbcon does not
sound like a good idea to me either.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>,
Sultan Alsawaf <sultan@kerneltoast.com>,
Anton Vorontsov <anton@enomsg.org>,
Ben Segall <bsegall@google.com>, Colin Cross <ccross@android.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
dri-devel@lists.freedesktop.org, Ingo Molnar <mingo@redhat.com>,
John Ogness <john.ogness@linutronix.de>,
Juri Lelli <juri.lelli@redhat.com>,
Kees Cook <keescook@chromium.org>,
linux-kernel@vger.kernel.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>, Mel Gorman <mgorman@suse.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Tony Luck <tony.luck@intel.com>,
Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: printk deadlock due to double lock attempt on current CPU's runqueue
Date: Wed, 10 Nov 2021 14:21:31 +0100 [thread overview]
Message-ID: <YYvHW1OpN1L2uInb@phenom.ffwll.local> (raw)
In-Reply-To: <YYuq5d7MYL2wxlOd@hirez.programming.kicks-ass.net>
On Wed, Nov 10, 2021 at 12:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 10, 2021 at 11:50:38AM +0100, Petr Mladek wrote:
> > On Tue 2021-11-09 12:06:48, Sultan Alsawaf wrote:
> > > Hi,
> > >
> > > I encountered a printk deadlock on 5.13 which appears to still affect the latest
> > > kernel. The deadlock occurs due to printk being used while having the current
> > > CPU's runqueue locked, and the underlying framebuffer console attempting to lock
> > > the same runqueue when printk tries to flush the log buffer.
> > >
> > > I'm not sure what the *correct* solution is here (don't use printk while having
> > > a runqueue locked? don't use schedule_work() from the fbcon path? tell printk
> > > to use one of its lock-less backends?), so I've cc'd all the relevant folks.
> >
> > At the moment, printk_deferred() could be used here. It defers the
> > console handling via irq_work().
>
> I think I've rejected that patch at least twice now :-) John's printk
> stuff will really land real soon now, right.
Yeah whacking all affected prinkt callers just because of fbcon does not
sound like a good idea to me either.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-11-10 13:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 20:06 printk deadlock due to double lock attempt on current CPU's runqueue Sultan Alsawaf
2021-11-09 20:06 ` Sultan Alsawaf
2021-11-09 21:38 ` Peter Zijlstra
2021-11-09 21:38 ` Peter Zijlstra
2021-11-10 9:00 ` Vincent Guittot
2021-11-10 9:00 ` Vincent Guittot
2021-11-10 10:45 ` Michal Koutný
2021-11-10 10:45 ` Michal Koutný
2021-11-10 19:50 ` Sultan Alsawaf
2021-11-10 19:50 ` Sultan Alsawaf
2021-11-12 7:50 ` Vincent Guittot
2021-11-12 7:50 ` Vincent Guittot
2021-11-10 9:37 ` Daniel Vetter
2021-11-10 9:37 ` Daniel Vetter
2021-11-10 10:07 ` John Ogness
2021-11-10 10:07 ` John Ogness
2021-11-10 10:44 ` Daniel Vetter
2021-11-10 10:44 ` Daniel Vetter
2021-11-10 20:03 ` Sultan Alsawaf
2021-11-10 20:03 ` Sultan Alsawaf
2021-11-11 8:28 ` John Ogness
2021-11-11 8:28 ` John Ogness
2021-11-11 9:27 ` Petr Mladek
2021-11-10 10:50 ` Petr Mladek
2021-11-10 10:50 ` Petr Mladek
2021-11-10 11:20 ` Peter Zijlstra
2021-11-10 11:20 ` Peter Zijlstra
2021-11-10 13:21 ` Daniel Vetter [this message]
2021-11-10 13:21 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YYvHW1OpN1L2uInb@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=anton@enomsg.org \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=ccross@android.com \
--cc=dietmar.eggemann@arm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=john.ogness@linutronix.de \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=sultan@kerneltoast.com \
--cc=tony.luck@intel.com \
--cc=tzimmermann@suse.de \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.