Skip to content
  1. Apr 13, 2020
    • William Dauchy's avatar
      net, ip_tunnel: fix interface lookup with no key · b57327db
      William Dauchy authored
      [ Upstream commit 25629fda ]
      
      when creating a new ipip interface with no local/remote configuration,
      the lookup is done with TUNNEL_NO_KEY flag, making it impossible to
      match the new interface (only possible match being fallback or metada
      case interface); e.g: `ip link add tunl1 type ipip dev eth0`
      
      To fix this case, adding a flag check before the key comparison so we
      permit to match an interface with no local/remote config; it also avoids
      breaking possible userland tools relying on TUNNEL_NO_KEY flag and
      uninitialised key.
      
      context being on my side, I'm creating an extra ipip interface attached
      to the physical one, and moving it to a dedicated namespace.
      
      Fixes: c5441932
      
       ("GRE: Refactor GRE tunneling code.")
      Signed-off-by: default avatarWilliam Dauchy <w.dauchy@criteo.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b57327db
    • Qian Cai's avatar
      ipv4: fix a RCU-list lock in fib_triestat_seq_show · 545d7421
      Qian Cai authored
      [ Upstream commit fbe4e0c1
      
       ]
      
      fib_triestat_seq_show() calls hlist_for_each_entry_rcu(tb, head,
      tb_hlist) without rcu_read_lock() will trigger a warning,
      
       net/ipv4/fib_trie.c:2579 RCU-list traversed in non-reader section!!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 1
       1 lock held by proc01/115277:
        #0: c0000014507acf00 (&p->lock){+.+.}-{3:3}, at: seq_read+0x58/0x670
      
       Call Trace:
        dump_stack+0xf4/0x164 (unreliable)
        lockdep_rcu_suspicious+0x140/0x164
        fib_triestat_seq_show+0x750/0x880
        seq_read+0x1a0/0x670
        proc_reg_read+0x10c/0x1b0
        __vfs_read+0x3c/0x70
        vfs_read+0xac/0x170
        ksys_read+0x7c/0x140
        system_call+0x5c/0x68
      
      Fix it by adding a pair of rcu_read_lock/unlock() and use
      cond_resched_rcu() to avoid the situation where walking of a large
      number of items  may prevent scheduling for a long time.
      
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      545d7421
  2. Apr 02, 2020