From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Subject: Re: ipmr, ip6mr: Unite dumproute flows
Date: Wed, 17 Oct 2018 21:49:30 +0300
Message-ID: <7e1a20a0-9ab2-5680-bde9-185c72242680@cumulusnetworks.com>
References: <c3d958d0-9916-48d9-ad8d-076cda75c93f@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: "David S. Miller" <davem@davemloft.net>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>
To: Colin Ian King <colin.king@canonical.com>,
        Yuval Mintz <yuvalm@mellanox.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-wm1-f44.google.com ([209.85.128.44]:50525 "EHLO
        mail-wm1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728183AbeJRCqg (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 17 Oct 2018 22:46:36 -0400
Received: by mail-wm1-f44.google.com with SMTP id i8-v6so3012684wmg.0
        for <netdev@vger.kernel.org>; Wed, 17 Oct 2018 11:49:35 -0700 (PDT)
In-Reply-To: <c3d958d0-9916-48d9-ad8d-076cda75c93f@canonical.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

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 <yuvalm@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 <nikolay@cumulusnetworks.com>
> Date:   Thu Jan 12 15:53:33 2017 +0100
> 
>     ipmr: improve hash scalability
> 
> commit 87c418bf1323d57140f4b448715f64de3fbb7e91
> Author: Yuval Mintz <yuvalm@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