1. 08 Oct, 2018 1 commit
    • David Howells's avatar
      rxrpc: Use the UDP encap_rcv hook · 5271953c
      David Howells authored
      Use the UDP encap_rcv hook to cut the bit out of the rxrpc packet reception
      in which a packet is placed onto the UDP receive queue and then immediately
      removed again by rxrpc.  Going via the queue in this manner seems like it
      should be unnecessary.
      
      This does, however, require the invention of a value to place in encap_type
      as that's one of the conditions to switch packets out to the encap_rcv
      hook.  Possibly the value doesn't actually matter for anything other than
      sockopts on the UDP socket, which aren't accessible outside of rxrpc
      anyway.
      
      This seems to cut a bit of time out of the time elapsed between each
      sk_buff being timestamped and turning up in rxrpc (the final number in the
      following trace excerpts).  I measured this by making the rxrpc_rx_packet
      trace point print the time elapsed between the skb being timestamped and
      the current time (in ns), e.g.:
      
      	... 424.278721: rxrpc_rx_packet: ...  ACK 25026
      
      So doing a 512MiB DIO read from my test server, with an unmodified kernel:
      
      	N       min     max     sum		mean    stddev
      	27605   2626    7581    7.83992e+07     2840.04 181.029
      
      and with the patch applied:
      
      	N       min     max     sum		mean    stddev
      	27547   1895    12165   6.77461e+07     2459.29 255.02
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      5271953c
  2. 05 Oct, 2018 12 commits
  3. 04 Oct, 2018 6 commits
    • Ido Schimmel's avatar
      team: Forbid enslaving team device to itself · 471b83bd
      Ido Schimmel authored
      team's ndo_add_slave() acquires 'team->lock' and later tries to open the
      newly enslaved device via dev_open(). This emits a 'NETDEV_UP' event
      that causes the VLAN driver to add VLAN 0 on the team device. team's
      ndo_vlan_rx_add_vid() will also try to acquire 'team->lock' and
      deadlock.
      
      Fix this by checking early at the enslavement function that a team
      device is not being enslaved to itself.
      
      A similar check was added to the bond driver in commit 09a89c21
      ("bonding: disallow enslaving a bond to itself").
      
      WARNING: possible recursive locking detected
      4.18.0-rc7+ #176 Not tainted
      --------------------------------------------
      syz-executor4/6391 is trying to acquire lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
      
      but task is already holding lock:
      (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&team->lock);
        lock(&team->lock);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      2 locks held by syz-executor4/6391:
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:77 [inline]
       #0: (____ptrval____) (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x412/0xc30 net/core/rtnetlink.c:4662
       #1: (____ptrval____) (&team->lock){+.+.}, at: team_add_slave+0xdb/0x1c30 drivers/net/team/team.c:1947
      
      stack backtrace:
      CPU: 1 PID: 6391 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #176
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
       print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
       check_deadlock kernel/locking/lockdep.c:1809 [inline]
       validate_chain kernel/locking/lockdep.c:2405 [inline]
       __lock_acquire.cold.64+0x1fb/0x486 kernel/locking/lockdep.c:3435
       lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
       __mutex_lock_common kernel/locking/mutex.c:757 [inline]
       __mutex_lock+0x176/0x1820 kernel/locking/mutex.c:894
       mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:909
       team_vlan_rx_add_vid+0x3b/0x1e0 drivers/net/team/team.c:1868
       vlan_add_rx_filter_info+0x14a/0x1d0 net/8021q/vlan_core.c:210
       __vlan_vid_add net/8021q/vlan_core.c:278 [inline]
       vlan_vid_add+0x63e/0x9d0 net/8021q/vlan_core.c:308
       vlan_device_event.cold.12+0x2a/0x2f net/8021q/vlan.c:381
       notifier_call_chain+0x180/0x390 kernel/notifier.c:93
       __raw_notifier_call_chain kernel/notifier.c:394 [inline]
       raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
       call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1735
       call_netdevice_notifiers net/core/dev.c:1753 [inline]
       dev_open+0x173/0x1b0 net/core/dev.c:1433
       team_port_add drivers/net/team/team.c:1219 [inline]
       team_add_slave+0xa8b/0x1c30 drivers/net/team/team.c:1948
       do_set_master+0x1c9/0x220 net/core/rtnetlink.c:2248
       do_setlink+0xba4/0x3e10 net/core/rtnetlink.c:2382
       rtnl_setlink+0x2a9/0x400 net/core/rtnetlink.c:2636
       rtnetlink_rcv_msg+0x46e/0xc30 net/core/rtnetlink.c:4665
       netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2455
       rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4683
       netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
       netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
       netlink_sendmsg+0xa18/0xfd0 net/netlink/af_netlink.c:1908
       sock_sendmsg_nosec net/socket.c:642 [inline]
       sock_sendmsg+0xd5/0x120 net/socket.c:652
       ___sys_sendmsg+0x7fd/0x930 net/socket.c:2126
       __sys_sendmsg+0x11d/0x290 net/socket.c:2164
       __do_sys_sendmsg net/socket.c:2173 [inline]
       __se_sys_sendmsg net/socket.c:2171 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2171
       do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x456b29
      Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f9706bf8c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007f9706bf96d4 RCX: 0000000000456b29
      RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
      RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000004d3548 R14: 00000000004c8227 R15: 0000000000000000
      
      Fixes: 87002b03 ("net: introduce vlan_vid_[add/del] and use them instead of direct [add/kill]_vid ndo calls")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-and-tested-by: syzbot+bd051aba086537515cdb@syzkaller.appspotmail.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      471b83bd
    • Yu Zhao's avatar
      net/usb: cancel pending work when unbinding smsc75xx · f7b2a56e
      Yu Zhao authored
      Cancel pending work before freeing smsc75xx private data structure
      during binding. This fixes the following crash in the driver:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      IP: mutex_lock+0x2b/0x3f
      <snipped>
      Workqueue: events smsc75xx_deferred_multicast_write [smsc75xx]
      task: ffff8caa83e85700 task.stack: ffff948b80518000
      RIP: 0010:mutex_lock+0x2b/0x3f
      <snipped>
      Call Trace:
       smsc75xx_deferred_multicast_write+0x40/0x1af [smsc75xx]
       process_one_work+0x18d/0x2fc
       worker_thread+0x1a2/0x269
       ? pr_cont_work+0x58/0x58
       kthread+0xfa/0x10a
       ? pr_cont_work+0x58/0x58
       ? rcu_read_unlock_sched_notrace+0x48/0x48
       ret_from_fork+0x22/0x40
      Signed-off-by: default avatarYu Zhao <yuzhao@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7b2a56e
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2018-10-04' of... · 9e15ff7b
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2018-10-04' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Just three small fixes:
       * fix use-after-free in regulatory code
       * fix rx-mgmt key flag in AP mode (mac80211)
       * fix wireless extensions compat code memory leak
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e15ff7b
    • David S. Miller's avatar
      Merge branch 'mlxsw-fixes' · b576eddb
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Couple of fixes
      
      First patch works around an hardware issue in Spectrum-2 where a field
      indicating the event type is always set to the same value. Since there
      are only two event types and they are reported using different queues,
      we can use the queue number to derive the event type.
      
      Second patch prevents a router interface (RIF) leakage when a VLAN
      device is deleted from on top a bridge device.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b576eddb
    • Ido Schimmel's avatar
      mlxsw: spectrum: Delete RIF when VLAN device is removed · c360867e
      Ido Schimmel authored
      In commit 602b74ed ("mlxsw: spectrum_switchdev: Do not leak RIFs
      when removing bridge") I handled the case where RIFs created for VLAN
      devices were not properly cleaned up when their real device (a bridge)
      was removed.
      
      However, I forgot to handle the case of the VLAN device itself being
      removed. Do so now when the VLAN device is being unlinked from its real
      device.
      
      Fixes: 99f44bb3 ("mlxsw: spectrum: Enable L3 interfaces on top of bridge devices")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reported-by: default avatarArtem Shvorin <art@qrator.net>
      Tested-by: default avatarArtem Shvorin <art@qrator.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c360867e
    • Nir Dotan's avatar
      mlxsw: pci: Derive event type from event queue number · f3c84a8e
      Nir Dotan authored
      Due to a hardware issue in Spectrum-2, the field event_type of the event
      queue element (EQE) has become reserved. It was used to distinguish between
      command interface completion events and completion events.
      
      Use queue number to determine event type, as command interface completion
      events are always received on EQ0 and mlxsw driver maps completion events
      to EQ1.
      
      Fixes: c3ab4354 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
      Signed-off-by: default avatarNir Dotan <nird@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3c84a8e
  4. 03 Oct, 2018 16 commits
  5. 02 Oct, 2018 5 commits