On Sun, Apr 18, 2021 at 10:06:41AM -0700, David Ahern wrote: > On 4/16/21 8:55 AM, Ido Schimmel wrote: > > From: Ido Schimmel <ido...@nvidia.com> > > > > Currently, a multi-part nexthop dump is restarted based on the number of > > nexthops that have been dumped so far. This can result in a lot of > > nexthops not being dumped when nexthops are simultaneously deleted: > > > > # ip nexthop | wc -l > > 65536 > > # ip nexthop flush > > Dump was interrupted and may be inconsistent. > > Flushed 36040 nexthops > > # ip nexthop | wc -l > > 29496 > > > > Instead, restart the dump based on the nexthop identifier (fixed number) > > of the last successfully dumped nexthop: > > > > # ip nexthop | wc -l > > 65536 > > # ip nexthop flush > > Dump was interrupted and may be inconsistent. > > Flushed 65536 nexthops > > # ip nexthop | wc -l > > 0 > > > > Reported-by: Maksym Yaremchuk <maks...@nvidia.com> > > Tested-by: Maksym Yaremchuk <maks...@nvidia.com> > > Signed-off-by: Ido Schimmel <ido...@nvidia.com> > > Reviewed-by: Petr Machata <pe...@nvidia.com> > > --- > > net/ipv4/nexthop.c | 14 ++++++-------- > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > Reviewed-by: David Ahern <dsah...@kernel.org>
Thanks > > Any reason not to put this in -net with a Fixes tag? I put it in the cover letter: "Targeting at net-next since this use case never worked, the flow is pretty obscure and such a large number of nexthops is unlikely to be used in any real-world scenario."
