From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Boqun Feng <boqun.feng@gmail.com>, Ingo Molnar <mingo@redhat.com>,
John Ogness <john.ogness@linutronix.de>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>, Petr Mladek <pmladek@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Waiman Long <longman@redhat.com>, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested()
Date: Mon, 26 Jun 2023 15:13:02 +0200 [thread overview]
Message-ID: <20230626131302.JsFNvwps@linutronix.de> (raw)
In-Reply-To: <20230626104831.GT4253@hirez.programming.kicks-ass.net>
On 2023-06-26 12:48:31 [+0200], Peter Zijlstra wrote:
>
> Don't be like that... just hate on prink like the rest of us. In fact,
> i've been patching out the actual printk code for years because its
> unusable garbage.
:)
> Will this actually still be a problem once all the fancy printk stuff
> lands? That shouldn't do synchronous prints except to 'atomic' consoles
> by default IIRC.
The fancy printk stuff should have synchronous printing in emergency
situations and threaded printing by default. But then I hear John saying
that there might be push back because atomic consoles may not be
available everywhere…
Anyway, the requirement for the deadlock to trigger, that Tetsuo Handa
is concerned here:
- lockdep enabled
- console and tty in use.
- tty_insert_flip_string_and_push_buffer() on one CPU with
tty_port::lock acquired followed with a memory allocation blocking on
read_seqbegin(&zonelist_update_seq) due the writer
- memory hotplug => __build_all_zonelists() acquiring
write_seqlock(&zonelist_update_seq) and now lockdep creates a splat.
This is accounted for if the lockdep annotation comes first (1/2 of
the series). But the unlock annotation of the seq unlock operation may
still create a splat so a possibility for a deadlock remains.
The requirement is _high_ and it hardly justifies ugly code.
Sebastian
next prev parent reply other threads:[~2023-06-26 13:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-23 17:12 [PATCH v2 0/2] seqlock,mm: lockdep annotation + write_seqlock_irqsave() Sebastian Andrzej Siewior
2023-06-23 17:12 ` [PATCH v2 1/2] seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested() Sebastian Andrzej Siewior
2023-06-24 6:54 ` Tetsuo Handa
2023-06-26 8:12 ` Sebastian Andrzej Siewior
2023-06-26 9:25 ` Tetsuo Handa
2023-06-26 10:48 ` Peter Zijlstra
2023-06-26 11:26 ` Tetsuo Handa
2023-06-26 11:35 ` Michal Hocko
2023-06-26 12:27 ` Tetsuo Handa
2023-06-26 13:16 ` Michal Hocko
2023-06-26 12:46 ` Sebastian Andrzej Siewior
2023-06-26 13:13 ` Sebastian Andrzej Siewior [this message]
2023-06-26 14:44 ` Petr Mladek
2023-06-28 12:14 ` Tetsuo Handa
2023-07-27 15:10 ` Sebastian Andrzej Siewior
2023-07-29 5:31 ` Tetsuo Handa
2023-07-29 11:05 ` Tetsuo Handa
2023-07-31 14:25 ` Michal Hocko
2023-08-03 13:18 ` Tetsuo Handa
2023-08-03 14:49 ` Michal Hocko
2023-08-04 13:27 ` Tetsuo Handa
2023-08-07 8:20 ` Michal Hocko
2023-06-26 12:56 ` Mel Gorman
2023-06-23 17:12 ` [PATCH v2 2/2] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save() Sebastian Andrzej Siewior
2023-06-23 18:17 ` Michal Hocko
2023-06-23 20:15 ` [PATCH v3 " Sebastian Andrzej Siewior
2023-06-26 7:56 ` David Hildenbrand
2023-06-26 13:14 ` Mel Gorman
2023-06-28 13:56 ` Michal Hocko
2023-06-25 2:27 ` [PATCH v2 0/2] seqlock,mm: lockdep annotation + write_seqlock_irqsave() Tetsuo Handa
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=20230626131302.JsFNvwps@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=john.ogness@linutronix.de \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox