From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>
Cc: "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
Lijun Ou <oulijun@huawei.com>,
"Wei Hu(Xavier)" <xavier.huwei@huawei.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RDMA/hns: Use 64-bit arithmetic instead of 32-bit
Date: Mon, 29 Oct 2018 12:07:44 +0200 [thread overview]
Message-ID: <20181029100744.GP3974@mtr-leonro.mtl.com> (raw)
In-Reply-To: <4bf459e9feb559270983530d2e3720e78a167b05.camel@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On Thu, Oct 18, 2018 at 08:17:10PM -0400, Doug Ledford wrote:
> On Thu, 2018-10-18 at 14:01 +0300, Leon Romanovsky wrote:
> > On Thu, Oct 18, 2018 at 10:02:58AM +0200, Gustavo A. R. Silva wrote:
> > > Cast *max_num_sg* to u64 in order to give the compiler complete
> > > information about the proper arithmetic to use.
> > >
> > > Notice that such variable is used in a context that expects an
> > > expression of type u64 (64 bits, unsigned) and the following
> > > expression is currently being evaluated using 32-bit
> > > arithmetic:
> >
> > And what is wrong with that?
> > Please fix static analyzer tool instead of fixing proper C code.
>
> Judging on the static analyzer tool's message, I don't see anything
> wrong with it. The code contains a potential unintentional overflow
> error. The author might have been well aware of the overflow and not
> cared and in that case this is valid C, but the analyzer has no way of
> knowing that, so it flags it for review. To silence the checker you
> could either cast the arithmetic to u64, or cast length to u32. Either
> would clear up the ambiguity. I guess I'm not seeing why you would
> blame the static checker in this case, it did the best it is possible
> for it to do.
You are right, static analyzer tools have no way to understand that this
overflow isn't possible. I was over excited to go to my vacation hence my
response. Sorry about that.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2018-10-29 10:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 8:02 [PATCH] RDMA/hns: Use 64-bit arithmetic instead of 32-bit Gustavo A. R. Silva
2018-10-18 11:01 ` Leon Romanovsky
2018-10-19 0:17 ` Doug Ledford
2018-10-29 10:07 ` Leon Romanovsky [this message]
2018-10-22 18:15 ` Jason Gunthorpe
2018-10-22 18:22 ` Gustavo A. R. Silva
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=20181029100744.GP3974@mtr-leonro.mtl.com \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=gustavo@embeddedor.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=oulijun@huawei.com \
--cc=xavier.huwei@huawei.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.