From: Leon Romanovsky <leon@kernel.org>
To: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IB/mlx5: Fix potential NULL dereference in query_device
Date: Thu, 9 Apr 2026 12:51:58 +0300 [thread overview]
Message-ID: <20260409095158.GE86584@unreal> (raw)
In-Reply-To: <20260331215744.17039-1-prathameshdeshpande7@gmail.com>
On Tue, Mar 31, 2026 at 10:57:36PM +0100, Prathamesh Deshpande wrote:
> On Tue, Mar 31, 2026 at 10:04:00PM +0300, Leon Romanovsky wrote:
> > Kernel-space callers don't use uverbs path. It is solely for the
> > user-space access.
>
> Hi Leon,
>
> Understood. Smatch flags this as an "inconsistent NULL check" because
> 'uhw' is explicitly checked at line 967 (if (uhw && ...)).
>
> If 'uhw' is guaranteed to be non-NULL in this path, would you prefer
> a patch removing the redundant check at line 967 instead? This would
> align the logic and silence the static analysis warning.
uhw is not guaranteed to be non-NULL in mlx5_ib_query_device(). This
function is used in both kernel and user-space paths. The only condition
that cannot occur is a caller providing a non-zero 'uhw_outlen' while
passing a NULL 'uhw' pointer.
If the caller provides 'uhw_outlen', then 'uhw' will always be present.
The reverse, however, is not always true. See:
944 static int mlx5_ib_query_device(struct ib_device *ibdev,
945 struct ib_device_attr *props,
946 struct ib_udata *uhw)
947 {
948 size_t uhw_outlen = (uhw) ? uhw->outlen : 0;
Thanks
>
> Thanks,
> Prathamesh
>
next prev parent reply other threads:[~2026-04-09 9:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202603311604.GD814676@unreal>
2026-03-31 21:57 ` [PATCH] IB/mlx5: Fix potential NULL dereference in query_device Prathamesh Deshpande
2026-04-09 9:51 ` Leon Romanovsky [this message]
2026-04-10 1:07 ` Prathamesh Deshpande
2026-03-31 1:44 Prathamesh Deshpande
2026-03-31 13:49 ` Leon Romanovsky
2026-03-31 18:25 ` Prathamesh Deshpande
2026-03-31 19:04 ` Leon Romanovsky
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=20260409095158.GE86584@unreal \
--to=leon@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=prathameshdeshpande7@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 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.