Re: [PATCH net] ipv6: rate-limit probes for neighbourless routes

[Sabrina Dubroca <sd@queasysnail.net>]

2018-10-12, 08:17:28 -0700, Eric Dumazet wrote:
> 
> 
> On 10/12/2018 07:22 AM, Sabrina Dubroca wrote:
> > When commit 270972554c91 ("[IPV6]: ROUTE: Add Router Reachability
> > Probing (RFC4191).") introduced router probing, the rt6_probe() function
> > required that a neighbour entry existed. This neighbour entry is used to
> > record the timestamp of the last probe via the ->updated field.
> > 
> > Later, commit 2152caea7196 ("ipv6: Do not depend on rt->n in rt6_probe().")
> > removed the requirement for a neighbour entry. Neighbourless routes skip
> > the interval check and are not rate-limited.
> > 
> 
> Interesting. Can you describe a little more what happens here ?

The machine gets two default routes, one valid, one via a gateway that
doesn't exist. Every time a packet is sent via the default route, we
probe the dead gateway, which doesn't have a neighbour entry. Since
there's no rate-limiting, we send too many neighbour solicitations,
disobeying the RFC.

> Could this explain gazillions of syzbot/syzkaller reports that have all in common :

That seems completely unrelated. That particular trace is about router
solicitations, not neighbour solicitations. This seems more like an
RCU issue.


> rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> rcu:    (detected by 0, t=10712 jiffies, g=90369, q=135)
>  <IRQ>
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> rcu: All QSes seen, last rcu_preempt kthread activity 10548 (4295003843-4294993295), jiffies_till_next_fqs=1, root ->qsmask 0x0
> syz-executor0   R
>   running task    
>  warn_alloc.cold.119+0xb7/0x1bd mm/page_alloc.c:3426
> 22896  7592   5826 0x8010000c
> Call Trace:
>  <IRQ>
>  sched_show_task.cold.83+0x2b6/0x30a kernel/sched/core.c:5296
>  __alloc_pages_slowpath+0x2667/0x2d80 mm/page_alloc.c:4297
>  print_other_cpu_stall.cold.79+0xa83/0xba5 kernel/rcu/tree.c:1430
>  check_cpu_stall kernel/rcu/tree.c:1557 [inline]
>  __rcu_pending kernel/rcu/tree.c:3276 [inline]
>  rcu_pending kernel/rcu/tree.c:3319 [inline]
>  rcu_check_callbacks+0xafc/0x1990 kernel/rcu/tree.c:2665
>  __alloc_pages_nodemask+0xa80/0xde0 mm/page_alloc.c:4390
>  __alloc_pages include/linux/gfp.h:473 [inline]
>  __alloc_pages_node include/linux/gfp.h:486 [inline]
>  kmem_getpages mm/slab.c:1409 [inline]
>  cache_grow_begin+0x91/0x8c0 mm/slab.c:2677
>  fallback_alloc+0x203/0x2e0 mm/slab.c:3219
>  ____cache_alloc_node+0x1c7/0x1e0 mm/slab.c:3287
>  slab_alloc_node mm/slab.c:3327 [inline]
>  kmem_cache_alloc_node+0xe3/0x730 mm/slab.c:3642
>  __alloc_skb+0x119/0x770 net/core/skbuff.c:193
>  alloc_skb include/linux/skbuff.h:997 [inline]
>  ndisc_alloc_skb+0x144/0x340 net/ipv6/ndisc.c:403
>  ndisc_send_rs+0x331/0x6e0 net/ipv6/ndisc.c:669
>  update_process_times+0x2d/0x70 kernel/time/timer.c:1636
>  addrconf_rs_timer+0x314/0x690 net/ipv6/addrconf.c:3836
>  tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
>  tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
>  __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
>  __hrtimer_run_queues+0x41c/0x10d0 kernel/time/hrtimer.c:1460
>  call_timer_fn+0x272/0x920 kernel/time/timer.c:1326
>  hrtimer_interrupt+0x313/0x780 kernel/time/hrtimer.c:1518 

-- 
Sabrina