2016-11-26 18:36:46

by Christophe JAILLET

[permalink] [raw]
Subject: [PATCH] bnx2fc: shift wrapping bug in bnx2fc_process_unsol_compl()

BNX2FC_NUM_ERR_BITS is 63. err_warn_bit_map is a u64. So, to make sure that
no shift wrapping will occur, we need need additionnal casting.

The same test is already done a few lines above and '(u64)1' is already
used there. So just do the same here.

Signed-off-by: Christophe JAILLET <[email protected]>
---
I guess that this could also be written with a '1ULL << i' which would be
cleaner and less verbose IMHO, but apparently this driver does not use
such things yet. So keep the current style with casting.
---
drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
index 5ff9f89c17c7..a9dccb3b49cc 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
@@ -829,7 +829,7 @@ static void bnx2fc_process_unsol_compl(struct bnx2fc_rport *tgt, u16 wqe)
((u64)err_entry->data.err_warn_bitmap_hi << 32) |
(u64)err_entry->data.err_warn_bitmap_lo;
for (i = 0; i < BNX2FC_NUM_ERR_BITS; i++) {
- if (err_warn_bit_map & (u64) (1 << i)) {
+ if (err_warn_bit_map & (u64)((u64)1 << i)) {
err_warn = i;
break;
}
--
2.9.3


2016-11-28 13:25:32

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH] bnx2fc: shift wrapping bug in bnx2fc_process_unsol_compl()

On Sat, Nov 26, 2016 at 07:36:29PM +0100, Christophe JAILLET wrote:
> BNX2FC_NUM_ERR_BITS is 63. err_warn_bit_map is a u64. So, to make sure that
> no shift wrapping will occur, we need need additionnal casting.
>
> The same test is already done a few lines above and '(u64)1' is already
> used there. So just do the same here.
>
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> I guess that this could also be written with a '1ULL << i' which would be
> cleaner and less verbose IMHO, but apparently this driver does not use
> such things yet. So keep the current style with casting.

Ugh... No. This is not code to emulate. Use 1ULL << i. Even if we
did the cast, you would only need one:

if (err_warn_bit_map & ((u64)1 << i)) {


regards,
dan carpenter

2016-11-28 17:05:50

by Laurence Oberman

[permalink] [raw]
Subject: Re: [PATCH] bnx2fc: shift wrapping bug in bnx2fc_process_unsol_compl()



----- Original Message -----
> From: "Christophe JAILLET" <[email protected]>
> To: [email protected], [email protected], "martin petersen" <[email protected]>
> Cc: [email protected], [email protected], [email protected], "Christophe JAILLET"
> <[email protected]>
> Sent: Saturday, November 26, 2016 1:36:29 PM
> Subject: [PATCH] bnx2fc: shift wrapping bug in bnx2fc_process_unsol_compl()
>
> BNX2FC_NUM_ERR_BITS is 63. err_warn_bit_map is a u64. So, to make sure that
> no shift wrapping will occur, we need need additionnal casting.
>
> The same test is already done a few lines above and '(u64)1' is already
> used there. So just do the same here.
>
> Signed-off-by: Christophe JAILLET <[email protected]>
> ---
> I guess that this could also be written with a '1ULL << i' which would be
> cleaner and less verbose IMHO, but apparently this driver does not use
> such things yet. So keep the current style with casting.
> ---
> drivers/scsi/bnx2fc/bnx2fc_hwi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> index 5ff9f89c17c7..a9dccb3b49cc 100644
> --- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> +++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
> @@ -829,7 +829,7 @@ static void bnx2fc_process_unsol_compl(struct
> bnx2fc_rport *tgt, u16 wqe)
> ((u64)err_entry->data.err_warn_bitmap_hi << 32) |
> (u64)err_entry->data.err_warn_bitmap_lo;
> for (i = 0; i < BNX2FC_NUM_ERR_BITS; i++) {
> - if (err_warn_bit_map & (u64) (1 << i)) {
> + if (err_warn_bit_map & (u64)((u64)1 << i)) {
> err_warn = i;
> break;
> }
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

Looks fine to me.
Reviewed-by: Laurence Oberman <[email protected]>