From: John Ogness <john.ogness@linutronix.de>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
syzbot+6cebc1af246fe020a2f0@syzkaller.appspotmail.com,
Daniel Vetter <daniel.vetter@intel.com>,
stable@vger.kernel.org,
Kent Overstreet <kent.overstreet@linux.dev>,
Brian Foster <bfoster@redhat.com>,
linux-bcachefs@vger.kernel.org, Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH 2/2] bcachefs: only console_trylock in bch2_print_string_as_lines
Date: Wed, 10 Jul 2024 13:08:42 +0206 [thread overview]
Message-ID: <87frsh33xp.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <20240710093120.732208-2-daniel.vetter@ffwll.ch>
On 2024-07-10, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> console_lock is the outermost subsystem lock for a lot of subsystems,
> which means get/put_user must nest within. Which means it cannot be
> acquired somewhere deeply nested in other locks, and most definitely
> not while holding fs locks potentially needed to resolve faults.
>
> console_trylock is the best we can do here.
>
> Including printk folks since even trylock feels realyl iffy here to
> me.
Using the console lock here at all is wrong. The console lock does not
prevent other CPUs from calling printk() and inserting lines in between.
There is no way to guarantee a contiguous ringbuffer block using
multiple printk() calls.
The console_lock usage should be removed.
John Ogness
next prev parent reply other threads:[~2024-07-10 11:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240710093120.732208-1-daniel.vetter@ffwll.ch>
2024-07-10 9:31 ` [PATCH 2/2] bcachefs: only console_trylock in bch2_print_string_as_lines Daniel Vetter
2024-07-10 11:02 ` John Ogness [this message]
2024-07-10 13:03 ` [PATCH] bcachefs: no console_lock " Daniel Vetter
2024-07-10 14:01 ` John Ogness
2024-07-10 14:13 ` John Ogness
2024-07-15 8:45 ` 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=87frsh33xp.fsf@jogness.linutronix.de \
--to=john.ogness@linutronix.de \
--cc=bfoster@redhat.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+6cebc1af246fe020a2f0@syzkaller.appspotmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox