From: Jakub Kicinski <kuba@kernel.org>
To: Slawomir Stepien <sst@poczta.fm>
Cc: syzbot <syzbot@kernel.org>,
syzkaller-bugs@googlegroups.com,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org, syzbot@lists.linux.dev
Subject: Re: [PATCH] netdevsim: fix deadlock in nsim_bus_dev_max_vfs_write()
Date: Fri, 7 Aug 2026 14:47:55 -0700 [thread overview]
Message-ID: <20260807144755.49141d2d@kernel.org> (raw)
In-Reply-To: <anWJyHCic8XvA0Q2@nr200>
On Fri, 7 Aug 2026 09:31:20 +0200 Slawomir Stepien wrote:
> That's true, but is netdevsim used *just* by the selftests (or was
> designed with only selftests in mind)? What if someone is using it
> without selftests?
Quoting documentation:
netdevsim
~~~~~~~~~
``netdevsim`` is a test driver which can be used to exercise driver
configuration APIs without requiring capable hardware.
Mock-ups and tests based on ``netdevsim`` are encouraged when
adding new APIs with complex logic in the stack. The tests should
be written so that they can run both against ``netdevsim`` and a real
device (see ``tools/testing/selftests/drivers/net/README.rst``).
``netdevsim``-only tests should focus on testing corner cases
and failure paths in the core which are hard to exercise with a real driver.
``netdevsim`` in itself is **not** considered
a use case/user. You must also implement the new APIs in a real driver.
We give no guarantees that ``netdevsim`` won't change in the future
in a way which would break what would normally be considered uAPI.
``netdevsim`` is reserved for use by upstream tests only, so any
new ``netdevsim`` features must be accompanied by selftests under
``tools/testing/selftests/``.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#netdevsim
> On the other hand: what sashiko found:
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/b7bf56ea-7522-4163-acd5-aaa69ad03b3a%40mail.kernel.org
> is true: the same issue will be with e.g. break_health. So it seems
> to me that a better approach would be to change when the debugfs
> files are removed.
I seem to recall being annoyed at the fact that the health API takes
devlink lock. It should be callable from IRQ even. Forcing drivers
to worry about calling context is annoying for real drivers too.
> It seems to me that change in nsim_drv_remove() might be easy, but
> what about nsim_dev_reload_down()...it seems it will have the same
> deadlock. Or am I missing something for this case?
netdevsim is just a test mock. Fixing it for the sake of fixing
netdevsim is a waste of everyone's time. The first question you should
be asking yourself is "do I understand what this code was *designed
for*"..
prev parent reply other threads:[~2026-08-07 21:47 UTC|newest]
Thread overview: 7+ 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
2026-08-05 8:55 ` Slawomir Stepien
2026-08-05 9:05 ` Paolo Abeni
2026-08-05 23:08 ` Jakub Kicinski
2026-08-07 7:31 ` Slawomir Stepien
2026-08-07 21:47 ` Jakub Kicinski [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=20260807144755.49141d2d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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