From: Jakub Kicinski <kuba@kernel.org>
To: Daniel Machon <daniel.machon@microchip.com>
Cc: Jiacheng Xu <stitch@zju.edu.cn>, <andrew+netdev@lunn.ch>,
<davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
<jiri@resnulli.us>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH net] netdevsim: avoid NULL dereference after failed probe
Date: Mon, 19 Oct 2026 19:25:05 -0700 [thread overview]
Message-ID: <20261019192505.5e7b1341@kernel.org> (raw)
In-Reply-To: <20261015080133.lv4rnnyuontntlkb@DEN-DL-M70577.microsemi.net>
On Thu, 15 Oct 2026 10:01:33 +0200 Daniel Machon wrote:
> There might be another approach though. Did you explore nsim_driver.dev_groups?
> Adding nsim_bus_dev_new_port_attr/nsim_bus_dev_del_port_attr there might work,
> and the fix will be simpler. I cant claim to be an expert in this area, but it
> might be wort investigating.
I had a similar feeling, but looks like nsim_bus_dev_numvfs_store()
already checks drvdata :\ Let's stick to this approach, but please
fix the flow to look identical to the check in numvfs_store:
device_lock(dev);
ret = -ENOENT;
if (dev_get_drvdata(dev))
ret = nsim_XXX(nsim_bus_dev, num_vfs);
device_unlock(dev);
Please make sure to include the info requested by the bot in next
version, namely:
- How the issue was discovered, e.g. hit in production, hit during
development, syzbot report, manual code inspection, LLM or static
analysis tool scan.
- Whether the issue was actually triggered, or is only theoretical
(e.g. found by code inspection). If it was triggered please include
the symptoms, like the stack trace or error messages.
--
pw-bot: cr
prev parent reply other threads:[~2026-10-20 2:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 13:59 [PATCH net] netdevsim: avoid NULL dereference after failed probe Jiacheng Xu
2026-10-12 14:04 ` netdev-bot+sinfo
2026-10-13 6:47 ` Hangbin Liu
2026-10-15 8:01 ` Daniel Machon
2026-10-20 2:25 ` 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=20261019192505.5e7b1341@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=daniel.machon@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=stitch@zju.edu.cn \
/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.