From: Paolo Abeni <pabeni@redhat.com>
To: syzbot <syzbot@kernel.org>,
syzkaller-bugs@googlegroups.com, Slawomir Stepien <sst@poczta.fm>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, syzbot@lists.linux.dev
Subject: Re: [PATCH] netdevsim: fix deadlock in nsim_bus_dev_max_vfs_write()
Date: Tue, 4 Aug 2026 16:33:34 +0200 [thread overview]
Message-ID: <c74a0579-dc37-4f3b-8dba-8380223b361c@redhat.com> (raw)
In-Reply-To: <b7bf56ea-7522-4163-acd5-aaa69ad03b3a@mail.kernel.org>
On 7/31/26 11:55 AM, syzbot wrote:
> From: Slawomir Stepien <sst@poczta.fm>
>
> There is an ABBA deadlock between the devlink instance lock and the debugfs
> active file reference mechanism.
>
> When a device is being removed (e.g., via nsim_drv_remove()), the driver
> acquires the devlink instance lock and then calls
> debugfs_remove_recursive(). This function blocks waiting for all active
> file operations on the debugfs files to complete.
>
> Concurrently, if a user writes to the "max_vfs" debugfs file, the VFS layer
> acquires an active reference to the file. The write handler,
> nsim_bus_dev_max_vfs_write(), then attempts to acquire the devlink instance
> lock, which is already held by the removal task.
>
> This creates a circular dependency resulting in a deadlock:
>
> INFO: task blocked for more than 143 seconds.
> Call Trace:
> wait_for_completion+0x2ca/0x5e0 kernel/sched/completion.c:153
> __debugfs_file_removed fs/debugfs/inode.c:751 [inline]
> remove_one+0x2df/0x3b0 fs/debugfs/inode.c:758
> __simple_recursive_removal+0x215/0x520 fs/libfs.c:623
> debugfs_remove+0x5b/0x70 fs/debugfs/inode.c:781
> nsim_dev_debugfs_exit drivers/net/netdevsim/dev.c:372 [inline]
> nsim_drv_remove+0xc0/0x170 drivers/net/netdevsim/dev.c:1803
>
> INFO: task blocked for more than 143 seconds.
> Call Trace:
> __mutex_lock+0x7bf/0x1550 kernel/locking/mutex.c:821
> nsim_bus_dev_max_vfs_write+0x229/0x3d0 drivers/net/netdevsim/dev.c:276
> full_proxy_write+0x127/0x1f0 fs/debugfs/file.c:388
> vfs_write+0x296/0xba0 fs/read_write.c:685
>
> To fix this, use devl_trylock() in nsim_bus_dev_max_vfs_write() instead of
> devl_lock(). If the lock cannot be acquired, return -EBUSY. This aborts the
> write operation, releases the debugfs active file reference, and allows the
> pending debugfs_remove_recursive() to proceed.
>
> Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot
> Reported-by: syzbot+3147c5de186107ffc7a1@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=3147c5de186107ffc7a1
> Link: https://syzkaller.appspot.com/ai_job?id=fcdda182-bebf-49ab-ada0-d4d2e814ebf7
> Signed-off-by: Slawomir Stepien <sst@poczta.fm>
>
> ---
> diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
> index aed9ad5f1..421cd7327 100644
> --- a/drivers/net/netdevsim/dev.c
> +++ b/drivers/net/netdevsim/dev.c
> @@ -273,7 +273,11 @@ static ssize_t nsim_bus_dev_max_vfs_write(struct file *file,
> return -ENOMEM;
>
> nsim_dev = file->private_data;
> - devl_lock(priv_to_devlink(nsim_dev));
> + if (!devl_trylock(priv_to_devlink(nsim_dev))) {
> + ret = -EBUSY;
I think this should return restart_syscall(). This kind of schema is
calling for trouble, but for netdevsim should be okish.
/P
next prev parent reply other threads:[~2026-08-04 14:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 9:55 [PATCH] netdevsim: fix deadlock in nsim_bus_dev_max_vfs_write() syzbot
2026-08-04 14:33 ` Paolo Abeni [this message]
2026-08-05 8:55 ` Slawomir Stepien
2026-08-05 9:05 ` Paolo Abeni
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=c74a0579-dc37-4f3b-8dba-8380223b361c@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sst@poczta.fm \
--cc=syzbot@kernel.org \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.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