From: Peter Zijlstra <peterz@infradead.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
syzbot <syzbot+23de6daeb71241d36a18@syzkaller.appspotmail.com>,
Liam.Howlett@oracle.com, akpm@linux-foundation.org,
jannh@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lorenzo.stoakes@oracle.com, pfalcato@suse.de,
syzkaller-bugs@googlegroups.com,
Suren Baghdasaryan <surenb@google.com>,
John Ogness <john.ogness@linutronix.de>
Subject: Re: [syzbot] [mm?] possible deadlock in __vma_start_write
Date: Thu, 5 Jun 2025 12:48:19 +0200 [thread overview]
Message-ID: <20250605104819.GP39944@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <aEFl9FWQHEJqnl2Q@pathway.suse.cz>
On Thu, Jun 05, 2025 at 11:40:04AM +0200, Petr Mladek wrote:
> I just wanted to better understand what was going on here ;-)
> Let me share my thoughts.
>
> First, the deadlock might happen only when all these (or similar) code
> paths might be called in parallel.
I've found that this is often easier than you think.
> The two backtraces, right above, are from initcalls. It is possible
> that the code path in the 1st backtrace can't be called before
> the device is initialized. So, it is possible that the deadlock
> can't happen in the real life.
This is a very shaky assumption. Lockdep only records the first time it
sees a particular order. So seeing an initcall in the stack trace only
means it happens first during an initcall. It does *NOT* mean it only
happens during initcall.
The only conclusion that can be had is that nobody thereafter uses those
locks in the reverse order -- because that would result in a splat.
prev parent reply other threads:[~2025-06-05 10:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-29 15:40 [syzbot] [mm?] possible deadlock in __vma_start_write syzbot
2025-06-02 13:04 ` Lorenzo Stoakes
2025-06-02 14:16 ` Suren Baghdasaryan
2025-06-02 14:19 ` Lorenzo Stoakes
2025-06-04 0:51 ` Suren Baghdasaryan
2025-06-04 5:17 ` Lorenzo Stoakes
2025-06-04 7:52 ` Vlastimil Babka
2025-06-04 8:31 ` John Ogness
2025-06-04 14:29 ` Suren Baghdasaryan
2025-06-05 9:40 ` Petr Mladek
2025-06-05 10:48 ` Peter Zijlstra [this message]
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=20250605104819.GP39944@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=pfalcato@suse.de \
--cc=pmladek@suse.com \
--cc=surenb@google.com \
--cc=syzbot+23de6daeb71241d36a18@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.cz \
/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.