From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Timur Tabi <timur@codeaurora.org>,
Sinan Kaya <okaya@codeaurora.org>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Doug Gilbert <dgilbert@interlog.com>,
"James E.J. Bottomley" <JBottomley@odin.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
jcm@redhat.com, Andy Gross <agross@codeaurora.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
cov@codeaurora.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V2 2/3] scsi: fix compiler warning for sg
Date: Tue, 10 Nov 2015 11:09:48 +0100 [thread overview]
Message-ID: <6427533.oLIG8d5C7c@wuerfel> (raw)
In-Reply-To: <5641783D.3030108@codeaurora.org>
On Monday 09 November 2015 22:53:17 Timur Tabi wrote:
> Sinan Kaya wrote:
> >
> > The code says it is using these macros for small integers only which
> > can't overflow. I was trying to get rid of compiler warning and it seems
> > to have disappeared.
>
> I would double-check the assembly code, if I were you. I don't like it
> when warnings just go away like that.
>
> Besides, we *should* be using do_div() for 64-bit division.
I stared at this code for some time and couldn't figure out whether it
is actually safe or not. The point here is that it doesn't actually do
a 64-bit division here:
MULDIV(INT_MAX, USER_HZ, HZ)
where all arguments are 32bit and it tries to figure out whether the
ioctl argument is too big to fit into a 32-bit number
but it does a 'long' division that happens to be 64-bit long on
architectures with the respective register size when it then does
sfp->timeout = MULDIV (val, HZ, USER_HZ);
to scale up the argument from USER_HZ to the possibly larger in-kernel
HZ value. So I think it's safe as is, but I'm still not entirely sure.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/3] scsi: fix compiler warning for sg
Date: Tue, 10 Nov 2015 11:09:48 +0100 [thread overview]
Message-ID: <6427533.oLIG8d5C7c@wuerfel> (raw)
In-Reply-To: <5641783D.3030108@codeaurora.org>
On Monday 09 November 2015 22:53:17 Timur Tabi wrote:
> Sinan Kaya wrote:
> >
> > The code says it is using these macros for small integers only which
> > can't overflow. I was trying to get rid of compiler warning and it seems
> > to have disappeared.
>
> I would double-check the assembly code, if I were you. I don't like it
> when warnings just go away like that.
>
> Besides, we *should* be using do_div() for 64-bit division.
I stared at this code for some time and couldn't figure out whether it
is actually safe or not. The point here is that it doesn't actually do
a 64-bit division here:
MULDIV(INT_MAX, USER_HZ, HZ)
where all arguments are 32bit and it tries to figure out whether the
ioctl argument is too big to fit into a 32-bit number
but it does a 'long' division that happens to be 64-bit long on
architectures with the respective register size when it then does
sfp->timeout = MULDIV (val, HZ, USER_HZ);
to scale up the argument from USER_HZ to the possibly larger in-kernel
HZ value. So I think it's safe as is, but I'm still not entirely sure.
Arnd
next prev parent reply other threads:[~2015-11-10 10:09 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 1:57 [PATCH V2 0/3] scsi: mptxsas: updates for ARM64 Sinan Kaya
2015-11-09 1:57 ` Sinan Kaya
2015-11-09 1:57 ` [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails Sinan Kaya
2015-11-09 1:57 ` Sinan Kaya
2015-11-09 7:09 ` Hannes Reinecke
2015-11-09 7:09 ` Hannes Reinecke
2015-11-09 8:59 ` Arnd Bergmann
2015-11-09 8:59 ` Arnd Bergmann
2015-11-09 14:07 ` Sinan Kaya
2015-11-09 14:07 ` Sinan Kaya
2015-11-09 14:33 ` Arnd Bergmann
2015-11-09 14:33 ` Arnd Bergmann
2015-11-09 23:22 ` Sinan Kaya
2015-11-09 23:22 ` Sinan Kaya
2015-11-09 23:29 ` Timur Tabi
2015-11-09 23:29 ` Timur Tabi
2015-11-10 8:38 ` Arnd Bergmann
2015-11-10 8:38 ` Arnd Bergmann
2015-11-10 16:06 ` Sinan Kaya
2015-11-10 16:06 ` Sinan Kaya
2015-11-10 16:47 ` Arnd Bergmann
2015-11-10 16:47 ` Arnd Bergmann
2015-11-10 17:00 ` Timur Tabi
2015-11-10 17:00 ` Timur Tabi
2015-11-10 19:13 ` Arnd Bergmann
2015-11-10 19:13 ` Arnd Bergmann
2015-11-10 21:03 ` Timur Tabi
2015-11-10 21:03 ` Timur Tabi
2015-11-10 21:54 ` Arnd Bergmann
2015-11-10 21:54 ` Arnd Bergmann
2015-11-10 21:59 ` Timur Tabi
2015-11-10 21:59 ` Timur Tabi
2015-11-10 22:08 ` Arnd Bergmann
2015-11-10 22:08 ` Arnd Bergmann
2015-11-10 17:19 ` Sinan Kaya
2015-11-10 17:19 ` Sinan Kaya
2015-11-10 18:27 ` James Bottomley
2015-11-10 18:27 ` James Bottomley
2015-11-10 19:14 ` Sinan Kaya
2015-11-10 19:14 ` Sinan Kaya
2015-11-10 19:43 ` James Bottomley
2015-11-10 19:43 ` James Bottomley
2015-11-10 19:56 ` Sinan Kaya
2015-11-10 19:56 ` Sinan Kaya
2015-11-10 20:05 ` James Bottomley
2015-11-10 20:05 ` James Bottomley
2015-11-10 20:26 ` Sinan Kaya
2015-11-10 20:26 ` Sinan Kaya
2015-11-10 20:35 ` James Bottomley
2015-11-10 20:35 ` James Bottomley
2015-11-10 19:56 ` Arnd Bergmann
2015-11-10 19:56 ` Arnd Bergmann
2015-11-10 20:58 ` Sinan Kaya
2015-11-10 20:58 ` Sinan Kaya
2015-11-10 22:06 ` Arnd Bergmann
2015-11-10 22:06 ` Arnd Bergmann
2015-11-09 14:00 ` Sinan Kaya
2015-11-09 14:00 ` Sinan Kaya
2015-11-09 1:57 ` [PATCH V2 2/3] scsi: fix compiler warning for sg Sinan Kaya
2015-11-09 1:57 ` Sinan Kaya
2015-11-09 14:14 ` Andy Shevchenko
2015-11-09 14:14 ` Andy Shevchenko
2015-11-10 3:21 ` Sinan Kaya
2015-11-10 3:21 ` Sinan Kaya
2015-11-10 3:21 ` Sinan Kaya
2015-11-10 3:26 ` Timur Tabi
2015-11-10 3:26 ` Timur Tabi
2015-11-10 4:51 ` Sinan Kaya
2015-11-10 4:51 ` Sinan Kaya
2015-11-10 4:53 ` Timur Tabi
2015-11-10 4:53 ` Timur Tabi
2015-11-10 9:23 ` Andy Shevchenko
2015-11-10 9:23 ` Andy Shevchenko
2015-11-10 10:09 ` Arnd Bergmann [this message]
2015-11-10 10:09 ` Arnd Bergmann
2015-11-09 1:57 ` [PATCH V2 3/3] scsi: mptxsas: offload IRQ execution Sinan Kaya
2015-11-09 1:57 ` Sinan Kaya
2015-11-09 7:15 ` Hannes Reinecke
2015-11-09 7:15 ` Hannes Reinecke
2015-11-09 14:01 ` Sinan Kaya
2015-11-09 14:01 ` Sinan Kaya
2015-11-10 5:59 ` Sinan Kaya
2015-11-10 5:59 ` Sinan Kaya
2015-11-10 5:59 ` Sinan Kaya
2016-03-16 15:31 ` Christopher Covington
2016-03-16 15:31 ` Christopher Covington
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=6427533.oLIG8d5C7c@wuerfel \
--to=arnd@arndb.de \
--cc=JBottomley@odin.com \
--cc=agross@codeaurora.org \
--cc=andy.shevchenko@gmail.com \
--cc=cov@codeaurora.org \
--cc=dgilbert@interlog.com \
--cc=jcm@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=okaya@codeaurora.org \
--cc=timur@codeaurora.org \
/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.