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.