From: Simon Horman <horms@kernel.org>
To: Zeeshan Ahmad <zeeshanahmad022019@gmail.com>
Cc: Sridhar Samudrala <sridhar.samudrala@intel.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v1] net: core: fix logical inconsistency in failover_slave_register()
Date: Thu, 19 Feb 2026 09:40:45 +0000 [thread overview]
Message-ID: <aZbanQC5ci7yLqzj@horms.kernel.org> (raw)
In-Reply-To: <20260219090216.12884-1-zeeshanahmad022019@gmail.com>
On Thu, Feb 19, 2026 at 02:02:16PM +0500, Zeeshan Ahmad wrote:
> Smatch warns that 'fops' is dereferenced at line 66 before being checked
> for NULL at line 85.
>
> The current code inconsistently assumes 'fops' might be NULL at lines 62
> and 85, while dereferencing it without a check at line 66.
>
> Move the NULL check to the beginning of the function immediately after
> 'fops' is initialized. This ensures safety for all subsequent
> dereferences and allows the removal of redundant checks.
>
> Signed-off-by: Zeeshan Ahmad <zeeshanahmad022019@gmail.com>
Hi Zeeshan,
It's not entirely clear to me what the behaviour should be if fops is
NULL, or indeed if fops can be NULL.
But looking over both this function and other users of failover_get_bymac()
it seems to me that the general patter is to skip steps that needs
to dereference fops if fops is NULL.
So I think it would be best to do the same here - that is modify the
code around line 66 to make it conditional on fops not being NULL.
Otherwise, if fops is NULL then steps that would have been taken are skipped.
It is true that in those steps would never be reached and the kernel would
have panic'ed due to a NULL dereference on line 66. So maybe your
approach is better, perhaps with the addition of a WARN_ON_ONCE.
But I feel that opens a larger surface that needs to be fixed in terms
of understanding other users of failover_get_bymac() and if they (still)
need to take fops being NULL into account.
LMKWYT
On process, if this is a fix - which I think means there is at least
a theoretical case where it can go *boom* - then please target at net
rather than net-next, and include a Fixes tag.
Else,
## Form letter - net-next-closed
We have already submitted our pull request with net-next material for v7.0,
and therefore net-next is closed for new drivers, features, code refactoring
and optimizations. We are currently accepting bug fixes only.
Please repost when net-next reopens after Feb 23rd.
RFC patches sent for review only are obviously welcome at any time.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle
--
pw-bot: defer
next prev parent reply other threads:[~2026-02-19 9:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 9:02 [PATCH net-next v1] net: core: fix logical inconsistency in failover_slave_register() Zeeshan Ahmad
2026-02-19 9:40 ` Simon Horman [this message]
2026-02-25 10:04 ` Zeeshan Ahmad
2026-02-25 13:31 ` Simon Horman
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=aZbanQC5ci7yLqzj@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sridhar.samudrala@intel.com \
--cc=zeeshanahmad022019@gmail.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