On 17/10/2018 22:34, Nikolay Aleksandrov wrote:
> If the skb space ends in an unresolved entry while dumping we'll miss
> some unresolved entries. The reason is due to zeroing the entry counter
> between dumping resolved and unresolved mfc entries. We should just
> keep counting until the whole table is dumped and zero when we move to
> the next as we have a separate table counter.
>
> Reported-by: Colin Ian King <colin.k...@canonical.com>
> Fixes: 8fb472c09b9d ("ipmr: improve hash scalability")
> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>
> ---
> Dropped Yuval's mail because it bounces.
>
> net/ipv4/ipmr_base.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/ipv4/ipmr_base.c b/net/ipv4/ipmr_base.c
> index 1ad9aa62a97b..eab8cd5ec2f5 100644
> --- a/net/ipv4/ipmr_base.c
> +++ b/net/ipv4/ipmr_base.c
> @@ -296,8 +296,6 @@ int mr_rtm_dumproute(struct sk_buff *skb, struct
> netlink_callback *cb,
> next_entry:
> e++;
> }
> - e = 0;
> - s_e = 0;
>
> spin_lock_bh(lock);
> list_for_each_entry(mfc, &mrt->mfc_unres_queue, list) {
>
+CC Colin
Sorry about that, my script somehow missed the reported-by email.
