From: Dan Carpenter <dan.carpenter@oracle.com>
To: izumi.taku@jp.fujitsu.com
Cc: netdev@vger.kernel.org
Subject: re: fjes: update_zone_task
Date: Mon, 14 Sep 2015 04:32:07 +0300 [thread overview]
Message-ID: <20150914013207.GA18438@mwanda> (raw)
Hello Taku Izumi,
The patch 785f28e061a8: "fjes: update_zone_task" from Aug 21, 2015,
leads to the following static checker warning:
drivers/net/fjes/fjes_hw.c:1016 fjes_hw_update_zone_task()
warn: potential off by one 'info[]' limit 'hw->max_epid'
drivers/net/fjes/fjes_hw.c
963 case 0:
964
965 for (epidx = 0; epidx < hw->max_epid; epidx++) {
966 if (epidx == hw->my_epid) {
967 hw->ep_shm_info[epidx].es_status =
968 info[epidx].es_status;
969 hw->ep_shm_info[epidx].zone =
970 info[epidx].zone;
971 continue;
972 }
973
974 pstatus = fjes_hw_get_partner_ep_status(hw, epidx);
975 switch (pstatus) {
976 case EP_PARTNER_UNSHARE:
977 default:
978 if ((info[epidx].zone !=
979 FJES_ZONING_ZONE_TYPE_NONE) &&
980 (info[epidx].es_status ==
981 FJES_ZONING_STATUS_ENABLE) &&
982 (info[epidx].zone ==
983 info[hw->my_epid].zone))
984 set_bit(epidx, &share_bit);
985 else
986 set_bit(epidx, &unshare_bit);
987 break;
988
989 case EP_PARTNER_COMPLETE:
990 case EP_PARTNER_WAITING:
991 if ((info[epidx].zone ==
992 FJES_ZONING_ZONE_TYPE_NONE) ||
993 (info[epidx].es_status !=
994 FJES_ZONING_STATUS_ENABLE) ||
995 (info[epidx].zone !=
996 info[hw->my_epid].zone)) {
997 set_bit(epidx,
998 &adapter->unshare_watch_bitmask);
999 set_bit(epidx,
1000 &hw->hw_info.buffer_unshare_reserve_bit);
1001 }
1002 break;
1003
1004 case EP_PARTNER_SHARED:
1005 if ((info[epidx].zone ==
1006 FJES_ZONING_ZONE_TYPE_NONE) ||
1007 (info[epidx].es_status !=
1008 FJES_ZONING_STATUS_ENABLE) ||
1009 (info[epidx].zone !=
1010 info[hw->my_epid].zone))
1011 set_bit(epidx, &irq_bit);
1012 break;
1013 }
1014 }
1015
1016 hw->ep_shm_info[epidx].es_status = info[epidx].es_status;
1017 hw->ep_shm_info[epidx].zone = info[epidx].zone;
I'm not sure how Smatch is able to generate this warning. The array is
allocated using the FJES_DEV_REQ_BUF_SIZE(hw->max_epid) macro. It
really has a lot of obfuscation layers so I wasn't able to understand
it.
It seems like this might be a real bug though. I suspect the fix is to
change the continue on line 970 to a break and delete lines 1016 and
1017?
1018
1019 break;
1020 }
regards,
dan carpenter
next reply other threads:[~2015-09-14 1:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 1:32 Dan Carpenter [this message]
2015-09-15 2:07 ` fjes: update_zone_task Izumi, Taku
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=20150914013207.GA18438@mwanda \
--to=dan.carpenter@oracle.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).