From: Oleg Nesterov <oleg@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
John Ogness <john.ogness@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] printk_legacy_map: use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP
Date: Fri, 24 Oct 2025 17:15:40 +0200 [thread overview]
Message-ID: <20251024151539.GG771@redhat.com> (raw)
In-Reply-To: <aPt3qje1IQU8i9Md@pathway.suse.cz>
So it seems that you guys finally have a consensus on this patch ;)
Should I send v3 or will you do it? I don't care about the "From:" tag.
If you want me to do it, let me ask:
On 10/24, Petr Mladek wrote:
>
> On Fri 2025-10-24 12:38:08, Sebastian Andrzej Siewior wrote:
> > The legacy console always acquires a spinlock_t from its printing
> > callback. This violates lock nesting if the caller acquired an always
> > spinning lock (raw_spinlock_t) while invoking printk(). This is not a
> > problem on PREEMPT_RT because legacy consoles print always from a
> > dedicated thread and never from within printk(). Therefore we tell
> > lockdep that a sleeping spin lock (spinlock_t) is valid here.
>
> Looks good to me.
Same here. Should I replace the whole comment block above
DEFINE_WAIT_OVERRIDE_MAP(printk_legacy_map) with the text above?
> > printk_legacy_map is used to hide lock nesting violations caused by
> > legacy drivers and is using the wrong override type. LD_WAIT_SLEEP is
> > for always sleeping lock types such as mutex_t. LD_WAIT_CONFIG is for
> > lock type which are sleeping while spinning on PREEMPT_RT such as
> > spinlock_t.
>
> Looks goot to me.
Same here. Should I add anything else into the changelog?
> JFYI, I do not mind which version is used.
Same here ;)
Oleg.
next prev parent reply other threads:[~2025-10-24 15:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 15:41 [PATCH] printk_legacy_map: use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP Oleg Nesterov
2025-10-23 7:49 ` Petr Mladek
2025-10-23 8:58 ` John Ogness
2025-10-23 10:28 ` Oleg Nesterov
2025-10-23 9:28 ` Oleg Nesterov
2025-10-23 10:32 ` [PATCH v2] " Oleg Nesterov
2025-10-23 14:26 ` Sebastian Andrzej Siewior
2025-10-23 15:06 ` John Ogness
2025-10-23 15:11 ` Sebastian Andrzej Siewior
2025-10-23 15:46 ` John Ogness
2025-10-23 15:46 ` Oleg Nesterov
2025-10-23 19:14 ` Sebastian Andrzej Siewior
2025-10-24 9:35 ` Petr Mladek
2025-10-24 10:38 ` Sebastian Andrzej Siewior
2025-10-24 12:57 ` Petr Mladek
2025-10-24 15:15 ` Oleg Nesterov [this message]
2025-10-24 10:40 ` Oleg Nesterov
2025-10-24 10:52 ` Sebastian Andrzej Siewior
2025-10-24 11:00 ` Oleg Nesterov
2025-10-26 15:07 ` [PATCH v3] " Oleg Nesterov
2025-10-27 8:28 ` Sebastian Andrzej Siewior
2025-10-27 8:37 ` John Ogness
2025-10-29 13:15 ` Petr Mladek
2025-10-29 17:00 ` Petr Mladek
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=20251024151539.GG771@redhat.com \
--to=oleg@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.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 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.