From: Dan Carpenter <dan.carpenter@linaro.org>
To: sunliming@linux.dev
Cc: lars@metafoo.de, Michael.Hennerich@analog.com,
nuno.sa@analog.com, jic23@kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, sunliming@kylinos.cn,
kernel test robot <lkp@intel.com>,
Dan Carpenter <error27@gmail.com>
Subject: Re: [PATCH] iio: imu: adis: fix uninitialized symbol warning
Date: Tue, 4 Mar 2025 09:36:56 +0300 [thread overview]
Message-ID: <c5b70fd8-2d03-4179-a8b8-5ee827fff978@stanley.mountain> (raw)
In-Reply-To: <20250304060518.1834910-1-sunliming@linux.dev>
On Tue, Mar 04, 2025 at 02:05:18PM +0800, sunliming@linux.dev wrote:
> From: sunliming <sunliming@kylinos.cn>
>
> Fix below kernel warning:
> smatch warnings:
> drivers/iio/imu/adis.c:319 __adis_check_status() error: uninitialized symbol 'status_16'.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <error27@gmail.com>
> Signed-off-by: sunliming <sunliming@kylinos.cn>
Huh... Someone is using lei to get their email. This patch is fine and
it's theoretically the correct thing to do.
How the zero-day bot warnings work is the they are first sent to my gmail
account and I look them over and either forward them or ignore them. Here
is the code:
drivers/iio/imu/adis.c
305 int __adis_check_status(struct adis *adis)
306 {
307 unsigned int status;
308 int diag_stat_bits;
309 u16 status_16;
310 int ret;
311 int i;
312
313 if (adis->data->diag_stat_size) {
314 ret = adis->ops->read(adis, adis->data->diag_stat_reg, &status,
315 adis->data->diag_stat_size);
316 } else {
317 ret = __adis_read_reg_16(adis, adis->data->diag_stat_reg,
318 &status_16);
319 status = status_16;
320 }
321 if (ret)
322 return ret;
323
So if __adis_read_reg_16() fails, then the next line is an uninitialized
read. But then the if (ret) check means that it's fine at run-time.
It's a false positive. The other thing to consider it the UBSan will
also detect the uninitialized read at runtime and splat. That's still a
false positive but it's a headache. But when I was looking at this, I
decided that __adis_read_reg_16() was unlikely to fail in real life so I
decided to ignore this warning.
Initializing the variable to zero doesn't change runtime for sane configs
because everyone automatically zeroes stack variables these days. It
just silences the Smatch warning. So I'm fine with this patch.
(This email is for information only in case you were wondering why the
bug report was formatted strangely etc).
regards,
dan carpenter
next prev parent reply other threads:[~2025-03-04 6:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 6:05 sunliming
2025-03-04 6:36 ` Dan Carpenter [this message]
2025-03-04 14:15 ` Jonathan Cameron
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=c5b70fd8-2d03-4179-a8b8-5ee827fff978@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=Michael.Hennerich@analog.com \
--cc=error27@gmail.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=nuno.sa@analog.com \
--cc=sunliming@kylinos.cn \
--cc=sunliming@linux.dev \
/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
all inboxes | Powered by JetHome®