On 17/10/2018 21:22, Colin Ian King wrote:
> Hi,
>
> Static analysis on linux-next has picked up a potential bug with commit:
>
> commit 7b0db85737db3f4d76b2a412e4f19eae59b8b494
> Author: Yuval Mintz <yuv...@mellanox.com>
> Date: Wed Feb 28 23:29:39 2018 +0200
>
> ipmr, ip6mr: Unite dumproute flows
>
> in function mr_table_dump(), s_e is and never seems to change, so the
> check if (e < s_e) is never true: See code below, as annotated by
> CoverityScan:
>
> 317 }
> assignment: Assigning: e = 0U.
>
> 318 e = 0;
> assignment: Assigning: s_e = 0U.
>
> 319 s_e = 0;
> 320
> 321 spin_lock_bh(lock);
> 322 list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
> at_least: At condition e < s_e, the value of e must be at least 0.
> const: At condition e < s_e, the value of s_e must be equal to 0.
> dead_error_condition: The condition e < s_e cannot be true.
>
> 323 if (e < s_e)
>
> CID 1474511 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: goto next_entry2;.
>
> 324 goto next_entry2;
> 325 if (filter->dev &&
> 326 !mr_mfc_uses_dev(mrt, mfc, filter->dev))
> 327 goto next_entry2;
> 328
> 329 err = fill(mrt, skb, NETLINK_CB(cb->skb).portid,
> 330 cb->nlh->nlmsg_seq, mfc, RTM_NEWROUTE, flags);
> 331 if (err < 0) {
> 332 spin_unlock_bh(lock);
> 333 goto out;
> 334 }
> 335next_entry2:
>
> incr: Incrementing e. The value of e is now 1.
> incr: Incrementing e. The value of e is now 2.
>
> 336 e++;
>
>
> Note that the zero'ing of e and s_e for ipmr and ip6mr was added in by
> earlier commits:
>
> commit 8fb472c09b9df478a062eacc7841448e40fc3c17
> Author: Nikolay Aleksandrov <niko...@cumulusnetworks.com>
> Date: Thu Jan 12 15:53:33 2017 +0100
>
> ipmr: improve hash scalability
>
> commit 87c418bf1323d57140f4b448715f64de3fbb7e91
> Author: Yuval Mintz <yuv...@mellanox.com>
> Date: Wed Feb 28 23:29:31 2018 +0200
>
> ip6mr: Align hash implementation to ipmr
>
> Anyhow, this looks incorrect, but I'm not familiar with this code to
> suggest the correct fix.
>
> Colin
>
Indeed, there's a case where we might miss an unresolved entry due to the
zeroing.
I'll send a fix shortly after testing.
Thanks,
Nik
