1. 28 Feb, 2019 13 commits
  2. 27 Feb, 2019 1 commit
  3. 26 Feb, 2019 20 commits
  4. 25 Feb, 2019 6 commits
    • Peter Oskolkov's avatar
      net: fix double-free in bpf_lwt_xmit_reroute · bd16693f
      Peter Oskolkov authored
      dst_output() frees skb when it fails (see, for example,
      ip_finish_output2), so it must not be freed in this case.
      
      Fixes: 3bd0b152 ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c")
      Signed-off-by: default avatarPeter Oskolkov <posk@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd16693f
    • wenxu's avatar
      ip_tunnel: Add ip tunnel tun_info type dst_cache in ip_tunnel_xmit · 186d9366
      wenxu authored
      ip l add dev tun type gretap key 1000
      
      Non-tunnel-dst ip tunnel device can send packet through lwtunnel
      This patch provide the tun_inf dst cache support for this mode.
      Signed-off-by: default avatarwenxu <wenxu@ucloud.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      186d9366
    • David S. Miller's avatar
      Merge branch 'dsa-mv88e6xxx-lockdep' · 169431ed
      David S. Miller authored
      Andrew Lunn says:
      
      ====================
      mv88e6xxx: Avoid false positive Lockdep splats
      
      When acquiring the GPIO interrupt line for the switch, it is possible
      to trigger lockdep splats. These are false positives, the mutex is in
      a different IRQ descriptor. But fix it anyway, since it could mask
      real locking issues.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      169431ed
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Release lock while requesting IRQ · 342a0ee7
      Andrew Lunn authored
      There is no need to hold the register lock while requesting the GPIO
      interrupt. By not holding it we can also avoid a false positive
      lockdep splat.
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      342a0ee7
    • Andrew Lunn's avatar
      net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat · f6d9758b
      Andrew Lunn authored
      The following false positive lockdep splat has been observed.
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.20.0+ #302 Not tainted
      ------------------------------------------------------
      systemd-udevd/160 is trying to acquire lock:
      edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
      
      but task is already holding lock:
      edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&desc->request_mutex){+.+.}:
             mutex_lock_nested+0x1c/0x24
             __setup_irq+0xa0/0x704
             request_threaded_irq+0xd0/0x150
             mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
             mdio_probe+0x2c/0x54
             really_probe+0x200/0x2c4
             driver_probe_device+0x5c/0x174
             __driver_attach+0xd8/0xdc
             bus_for_each_dev+0x58/0x7c
             bus_add_driver+0xe4/0x1f0
             driver_register+0x7c/0x110
             mdio_driver_register+0x24/0x58
             do_one_initcall+0x74/0x2e8
             do_init_module+0x60/0x1d0
             load_module+0x1968/0x1ff4
             sys_finit_module+0x8c/0x98
             ret_fast_syscall+0x0/0x28
             0xbedf2ae8
      
      -> #0 (&chip->reg_lock){+.+.}:
             __mutex_lock+0x50/0x8b8
             mutex_lock_nested+0x1c/0x24
             __setup_irq+0x640/0x704
             request_threaded_irq+0xd0/0x150
             mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
             mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
             mdio_probe+0x2c/0x54
             really_probe+0x200/0x2c4
             driver_probe_device+0x5c/0x174
             __driver_attach+0xd8/0xdc
             bus_for_each_dev+0x58/0x7c
             bus_add_driver+0xe4/0x1f0
             driver_register+0x7c/0x110
             mdio_driver_register+0x24/0x58
             do_one_initcall+0x74/0x2e8
             do_init_module+0x60/0x1d0
             load_module+0x1968/0x1ff4
             sys_finit_module+0x8c/0x98
             ret_fast_syscall+0x0/0x28
             0xbedf2ae8
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&desc->request_mutex);
                                     lock(&chip->reg_lock);
                                     lock(&desc->request_mutex);
        lock(&chip->reg_lock);
      
      &desc->request_mutex refer to two different mutex. #1 is the GPIO for
      the chip interrupt. #2 is the chained interrupt between global 1 and
      global 2.
      
      Add lockdep classes to the GPIO interrupt to avoid this.
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6d9758b
    • wenxu's avatar
      ip_tunnel: Add dst_cache support in lwtunnel_state of ip tunnel · 3d25eabb
      wenxu authored
      The lwtunnel_state is not init the dst_cache Which make the
      ip_md_tunnel_xmit can't use the dst_cache. It will lookup
      route table every packets.
      Signed-off-by: default avatarwenxu <wenxu@ucloud.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d25eabb