On Fri, 2017-01-27 at 10:06 +, Augusto Mecking Caringi wrote:
> On Thu, Jan 26, 2017 at 3:11 PM, Bart Van Assche
> wrote:
> > This patch is wrong. The purpose of the dev_loss_tmo >= LONG_MAX / HZ check
> > is to avoid that the expression 1UL * dev_loss_tmo * HZ further down
> > overflows. Can
On Thu, Jan 26, 2017 at 3:11 PM, Bart Van Assche
wrote:
> This patch is wrong. The purpose of the dev_loss_tmo >= LONG_MAX / HZ check
> is to avoid that the expression 1UL * dev_loss_tmo * HZ further down
> overflows. Can you check whether changing the if-statement into if (1UL *
> dev_loss_tmo >=
On Thu, 2017-01-26 at 11:17 +, Augusto Mecking Caringi wrote:
> In a 64bit system (where long is 64bit wide), even dividing LONG_MAX by
> HZ will always be bigger than the max value that an int variable can
> hold.
>
> This has been detected by building the driver with W=1:
>
> drivers/scsi/s
In a 64bit system (where long is 64bit wide), even dividing LONG_MAX by
HZ will always be bigger than the max value that an int variable can
hold.
This has been detected by building the driver with W=1:
drivers/scsi/scsi_transport_srp.c: In function ‘srp_tmo_valid’:
drivers/scsi/scsi_transport_sr
4 matches
Mail list logo