From: John Ogness <john.ogness@linutronix.de>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: Juri Lelli <juri.lelli@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
dri-devel@lists.freedesktop.org, Ben Segall <bsegall@google.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Anton Vorontsov <anton@enomsg.org>,
David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
Mel Gorman <mgorman@suse.de>, Petr Mladek <pmladek@suse.com>,
Kees Cook <keescook@chromium.org>,
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>,
mkoutny@suse.com, 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: Thu, 11 Nov 2021 09:34:00 +0106 [thread overview]
Message-ID: <87k0hfqepb.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <YYwlnEQO0raDwS86@sultan-box.localdomain>
On 2021-11-10, Sultan Alsawaf <sultan@kerneltoast.com> wrote:
> On Wed, Nov 10, 2021 at 11:13:37AM +0106, John Ogness wrote:
>> Even after we introduce kthread printers, there will still be
>> situations where direct printing is used: booting (before kthreads
>> exist) and shutdown/suspend/crash situations, when the kthreads may
>> not be active.
>
> Although I'm unaware of any ongoing kthread printer work, I'm curious
> to know how a kthread approach wouldn't employ a try_to_wake_up() from
> directly inside printk(), since the try_to_wake_up() hit from inside
> the fbcon code is what caused my deadlock.
The kthread approach triggers irq_work from printk(). The kthread
printer is then woken from the irq_work.
John Ogness
WARNING: multiple messages have this Message-ID (diff)
From: John Ogness <john.ogness@linutronix.de>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
Peter Zijlstra <peterz@infradead.org>,
Anton Vorontsov <anton@enomsg.org>,
Ben Segall <bsegall@google.com>, Colin Cross <ccross@android.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
David Airlie <airlied@linux.ie>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
dri-devel@lists.freedesktop.org, Ingo Molnar <mingo@redhat.com>,
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>,
Petr Mladek <pmladek@suse.com>,
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>,
mkoutny@suse.com
Subject: Re: printk deadlock due to double lock attempt on current CPU's runqueue
Date: Thu, 11 Nov 2021 09:34:00 +0106 [thread overview]
Message-ID: <87k0hfqepb.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <YYwlnEQO0raDwS86@sultan-box.localdomain>
On 2021-11-10, Sultan Alsawaf <sultan@kerneltoast.com> wrote:
> On Wed, Nov 10, 2021 at 11:13:37AM +0106, John Ogness wrote:
>> Even after we introduce kthread printers, there will still be
>> situations where direct printing is used: booting (before kthreads
>> exist) and shutdown/suspend/crash situations, when the kthreads may
>> not be active.
>
> Although I'm unaware of any ongoing kthread printer work, I'm curious
> to know how a kthread approach wouldn't employ a try_to_wake_up() from
> directly inside printk(), since the try_to_wake_up() hit from inside
> the fbcon code is what caused my deadlock.
The kthread approach triggers irq_work from printk(). The kthread
printer is then woken from the irq_work.
John Ogness
next prev parent reply other threads:[~2021-11-11 8:28 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 [this message]
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
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=87k0hfqepb.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--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=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.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.