[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1d6b8e045353c98c22ae7963d16d91c5a5421fd8.camel@linux.ibm.com>
Date: Wed, 11 Aug 2021 06:58:31 -0700
From: James Bottomley <jejb@...ux.ibm.com>
To: Tuo Li <islituo@...il.com>, kashyap.desai@...adcom.com,
sumit.saxena@...adcom.com, shivasharan.srikanteshwara@...adcom.com,
martin.petersen@...cle.com
Cc: megaraidlinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, baijiaju1990@...il.com,
TOTE Robot <oslab@...nghua.edu.cn>
Subject: Re: [PATCH] [SCSI] megaraid_sas: Fix possible divide-by-zero bugs
in megaraid_sas_fp.c
On Wed, 2021-08-11 at 06:16 -0700, Tuo Li wrote:
> In the function mega_mod64(). the variable is checked in:
> if (!divisor)
>
> This indicates that divisor can be zero.
> If so, a divide-by-zero bug will occur:
> remainder = do_div(d, divisor);
>
> Also, in the function mega_div64_32(), a divide-by-zero bug can also
> occur if divisor is NULL.
>
> To fix these divide-by-zero bugs, the functions return 0 if divisor
> is zero.
How exactly is this fixing anything? Simply returning zero because
there is a dividion by zero isn't a fix unless you know what that
return is going to do. If you look at the inputs to all the
mega_div/mod functions, they're already checked for zero divisor before
calling, so the error handling is already being done correctly and this
"fix" would add nothing to that. You can argue that the check and
print is pointless since the condition never occurs, but it's not
exactly fast path code.
James
Powered by blists - more mailing lists