1. 26 3月, 2020 1 次提交
  2. 05 3月, 2020 7 次提交
  3. 01 3月, 2020 1 次提交
    • W
      macintosh: therm_windtunnel: fix regression when instantiating devices · 38b17afb
      Wolfram Sang 提交于
      Removing attach_adapter from this driver caused a regression for at
      least some machines. Those machines had the sensors described in their
      DT, too, so they didn't need manual creation of the sensor devices. The
      old code worked, though, because manual creation came first. Creation of
      DT devices then failed later and caused error logs, but the sensors
      worked nonetheless because of the manually created devices.
      
      When removing attach_adaper, manual creation now comes later and loses
      the race. The sensor devices were already registered via DT, yet with
      another binding, so the driver could not be bound to it.
      
      This fix refactors the code to remove the race and only manually creates
      devices if there are no DT nodes present. Also, the DT binding is updated
      to match both, the DT and manually created devices. Because we don't
      know which device creation will be used at runtime, the code to start
      the kthread is moved to do_probe() which will be called by both methods.
      
      Fixes: 3e7bed52 ("macintosh: therm_windtunnel: drop using attach_adapter")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201723Reported-by: NErhard Furtner <erhard_f@mailbox.org>
      Tested-by: NErhard Furtner <erhard_f@mailbox.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org # v4.19+
      38b17afb
  4. 28 2月, 2020 17 次提交
    • A
      net: dsa: mv88e6xxx: Fix masking of egress port · 3ee339eb
      Andrew Lunn 提交于
      Add missing ~ to the usage of the mask.
      Reported-by: NKevin Benson <Kevin.Benson@zii.aero>
      Reported-by: NChris Healy <Chris.Healy@zii.aero>
      Fixes: 5c74c54c ("net: dsa: mv88e6xxx: Split monitor port configuration")
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ee339eb
    • A
      mlxsw: pci: Wait longer before accessing the device after reset · ac004e84
      Amit Cohen 提交于
      During initialization the driver issues a reset to the device and waits
      for 100ms before checking if the firmware is ready. The waiting is
      necessary because before that the device is irresponsive and the first
      read can result in a completion timeout.
      
      While 100ms is sufficient for Spectrum-1 and Spectrum-2, it is
      insufficient for Spectrum-3.
      
      Fix this by increasing the timeout to 200ms.
      
      Fixes: da382875 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC")
      Signed-off-by: NAmit Cohen <amitc@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac004e84
    • A
      sfc: fix timestamp reconstruction at 16-bit rollover points · 23797b98
      Alex Maftei (amaftei) 提交于
      We can't just use the top bits of the last sync event as they could be
      off-by-one every 65,536 seconds, giving an error in reconstruction of
      65,536 seconds.
      
      This patch uses the difference in the bottom 16 bits (mod 2^16) to
      calculate an offset that needs to be applied to the last sync event to
      get to the current time.
      Signed-off-by: NAlexandru-Mihai Maftei <amaftei@solarflare.com>
      Acked-by: NMartin Habets <mhabets@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23797b98
    • T
      net: rmnet: fix packet forwarding in rmnet bridge mode · ad3cc31b
      Taehee Yoo 提交于
      Packet forwarding is not working in rmnet bridge mode.
      Because when a packet is forwarded, skb_push() for an ethernet header
      is needed. But it doesn't call skb_push().
      So, the ethernet header will be lost.
      
      Test commands:
          modprobe rmnet
          ip netns add nst
          ip netns add nst2
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst2
      
          ip link add rmnet0 link veth0 type rmnet mux_id 1
          ip link set veth2 master rmnet0
          ip link set veth0 up
          ip link set veth2 up
          ip link set rmnet0 up
          ip a a 192.168.100.1/24 dev rmnet0
      
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip a a 192.168.100.2/24 dev veth1
          ip netns exec nst2 ip link set veth3 up
          ip netns exec nst2 ip a a 192.168.100.3/24 dev veth3
          ip netns exec nst2 ping 192.168.100.2
      
      Fixes: 60d58f97 ("net: qualcomm: rmnet: Implement bridge mode")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ad3cc31b
    • T
      net: rmnet: fix bridge mode bugs · d939b6d3
      Taehee Yoo 提交于
      In order to attach a bridge interface to the rmnet interface,
      "master" operation is used.
      (e.g. ip link set dummy1 master rmnet0)
      But, in the rmnet_add_bridge(), which is a callback of ->ndo_add_slave()
      doesn't register lower interface.
      So, ->ndo_del_slave() doesn't work.
      There are other problems too.
      1. It couldn't detect circular upper/lower interface relationship.
      2. It couldn't prevent stack overflow because of too deep depth
      of upper/lower interface
      3. It doesn't check the number of lower interfaces.
      4. Panics because of several reasons.
      
      The root problem of these issues is actually the same.
      So, in this patch, these all problems will be fixed.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link add dummy1 master rmnet0 type dummy
          ip link add dummy2 master rmnet0 type dummy
          ip link del rmnet0
          ip link del dummy2
          ip link del dummy1
      
      Splat looks like:
      [   41.867595][ T1164] general protection fault, probably for non-canonical address 0xdffffc0000000101I
      [   41.869993][ T1164] KASAN: null-ptr-deref in range [0x0000000000000808-0x000000000000080f]
      [   41.872950][ T1164] CPU: 0 PID: 1164 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   41.873915][ T1164] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   41.875161][ T1164] RIP: 0010:rmnet_unregister_bridge.isra.6+0x71/0xf0 [rmnet]
      [   41.876178][ T1164] Code: 48 89 ef 48 89 c6 5b 5d e9 fc fe ff ff e8 f7 f3 ff ff 48 8d b8 08 08 00 00 48 ba 00 7
      [   41.878925][ T1164] RSP: 0018:ffff8880c4d0f188 EFLAGS: 00010202
      [   41.879774][ T1164] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000101
      [   41.887689][ T1164] RDX: dffffc0000000000 RSI: ffffffffb8cf64f0 RDI: 0000000000000808
      [   41.888727][ T1164] RBP: ffff8880c40e4000 R08: ffffed101b3c0e3c R09: 0000000000000001
      [   41.889749][ T1164] R10: 0000000000000001 R11: ffffed101b3c0e3b R12: 1ffff110189a1e3c
      [   41.890783][ T1164] R13: ffff8880c4d0f200 R14: ffffffffb8d56160 R15: ffff8880ccc2c000
      [   41.891794][ T1164] FS:  00007f4300edc0c0(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
      [   41.892953][ T1164] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   41.893800][ T1164] CR2: 00007f43003bc8c0 CR3: 00000000ca53e001 CR4: 00000000000606f0
      [   41.894824][ T1164] Call Trace:
      [   41.895274][ T1164]  ? rcu_is_watching+0x2c/0x80
      [   41.895895][ T1164]  rmnet_config_notify_cb+0x1f7/0x590 [rmnet]
      [   41.896687][ T1164]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   41.897611][ T1164]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   41.898508][ T1164]  ? __module_text_address+0x13/0x140
      [   41.899162][ T1164]  notifier_call_chain+0x90/0x160
      [   41.899814][ T1164]  rollback_registered_many+0x660/0xcf0
      [   41.900544][ T1164]  ? netif_set_real_num_tx_queues+0x780/0x780
      [   41.901316][ T1164]  ? __lock_acquire+0xdfe/0x3de0
      [   41.901958][ T1164]  ? memset+0x1f/0x40
      [   41.902468][ T1164]  ? __nla_validate_parse+0x98/0x1ab0
      [   41.903166][ T1164]  unregister_netdevice_many.part.133+0x13/0x1b0
      [   41.903988][ T1164]  rtnl_delete_link+0xbc/0x100
      [ ... ]
      
      Fixes: 60d58f97 ("net: qualcomm: rmnet: Implement bridge mode")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d939b6d3
    • T
      net: rmnet: use upper/lower device infrastructure · 037f9cdf
      Taehee Yoo 提交于
      netdev_upper_dev_link() is useful to manage lower/upper interfaces.
      And this function internally validates looping, maximum depth.
      All or most virtual interfaces that could have a real interface
      (e.g. macsec, macvlan, ipvlan etc.) use lower/upper infrastructure.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet1 link dummy0 type rmnet mux_id 1
          for i in {2..100}
          do
              let A=$i-1
              ip link add rmnet$i link rmnet$A type rmnet mux_id $i
          done
          ip link del dummy0
      
      The purpose of the test commands is to make stack overflow.
      
      Splat looks like:
      [   52.411438][ T1395] BUG: KASAN: slab-out-of-bounds in find_busiest_group+0x27e/0x2c00
      [   52.413218][ T1395] Write of size 64 at addr ffff8880c774bde0 by task ip/1395
      [   52.414841][ T1395]
      [   52.430720][ T1395] CPU: 1 PID: 1395 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   52.496511][ T1395] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   52.513597][ T1395] Call Trace:
      [   52.546516][ T1395]
      [   52.558773][ T1395] Allocated by task 3171537984:
      [   52.588290][ T1395] BUG: unable to handle page fault for address: ffffffffb999e260
      [   52.589311][ T1395] #PF: supervisor read access in kernel mode
      [   52.590529][ T1395] #PF: error_code(0x0000) - not-present page
      [   52.591374][ T1395] PGD d6818067 P4D d6818067 PUD d6819063 PMD 0
      [   52.592288][ T1395] Thread overran stack, or stack corrupted
      [   52.604980][ T1395] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [   52.605856][ T1395] CPU: 1 PID: 1395 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   52.611764][ T1395] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   52.621520][ T1395] RIP: 0010:stack_depot_fetch+0x10/0x30
      [   52.622296][ T1395] Code: ff e9 f9 fe ff ff 48 89 df e8 9c 1d 91 ff e9 ca fe ff ff cc cc cc cc cc cc cc 89 f8 0
      [   52.627887][ T1395] RSP: 0018:ffff8880c774bb60 EFLAGS: 00010006
      [   52.628735][ T1395] RAX: 00000000001f8880 RBX: ffff8880c774d140 RCX: 0000000000000000
      [   52.631773][ T1395] RDX: 000000000000001d RSI: ffff8880c774bb68 RDI: 0000000000003ff0
      [   52.649584][ T1395] RBP: ffffea00031dd200 R08: ffffed101b43e403 R09: ffffed101b43e403
      [   52.674857][ T1395] R10: 0000000000000001 R11: ffffed101b43e402 R12: ffff8880d900e5c0
      [   52.678257][ T1395] R13: ffff8880c774c000 R14: 0000000000000000 R15: dffffc0000000000
      [   52.694541][ T1395] FS:  00007fe867f6e0c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [   52.764039][ T1395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   52.815008][ T1395] CR2: ffffffffb999e260 CR3: 00000000c26aa005 CR4: 00000000000606e0
      [   52.862312][ T1395] Call Trace:
      [   52.887133][ T1395] Modules linked in: dummy rmnet veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_dex
      [   52.936749][ T1395] CR2: ffffffffb999e260
      [   52.965695][ T1395] ---[ end trace 7e32ca99482dbb31 ]---
      [   52.966556][ T1395] RIP: 0010:stack_depot_fetch+0x10/0x30
      [   52.971083][ T1395] Code: ff e9 f9 fe ff ff 48 89 df e8 9c 1d 91 ff e9 ca fe ff ff cc cc cc cc cc cc cc 89 f8 0
      [   53.003650][ T1395] RSP: 0018:ffff8880c774bb60 EFLAGS: 00010006
      [   53.043183][ T1395] RAX: 00000000001f8880 RBX: ffff8880c774d140 RCX: 0000000000000000
      [   53.076480][ T1395] RDX: 000000000000001d RSI: ffff8880c774bb68 RDI: 0000000000003ff0
      [   53.093858][ T1395] RBP: ffffea00031dd200 R08: ffffed101b43e403 R09: ffffed101b43e403
      [   53.112795][ T1395] R10: 0000000000000001 R11: ffffed101b43e402 R12: ffff8880d900e5c0
      [   53.139837][ T1395] R13: ffff8880c774c000 R14: 0000000000000000 R15: dffffc0000000000
      [   53.141500][ T1395] FS:  00007fe867f6e0c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [   53.143343][ T1395] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   53.152007][ T1395] CR2: ffffffffb999e260 CR3: 00000000c26aa005 CR4: 00000000000606e0
      [   53.156459][ T1395] Kernel panic - not syncing: Fatal exception
      [   54.213570][ T1395] Shutting down cpus with NMI
      [   54.354112][ T1395] Kernel Offset: 0x33000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0x)
      [   54.355687][ T1395] Rebooting in 5 seconds..
      
      Fixes: b37f78f2 ("net: qualcomm: rmnet: Fix crash on real dev unregistration")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      037f9cdf
    • T
      net: rmnet: do not allow to change mux id if mux id is duplicated · 1dc49e9d
      Taehee Yoo 提交于
      Basically, duplicate mux id isn't be allowed.
      So, the creation of rmnet will be failed if there is duplicate mux id
      is existing.
      But, changelink routine doesn't check duplicate mux id.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link add rmnet1 link dummy0 type rmnet mux_id 2
          ip link set rmnet1 type rmnet mux_id 1
      
      Fixes: 23790ef1 ("net: qualcomm: rmnet: Allow to configure flags for existing devices")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1dc49e9d
    • T
      net: rmnet: remove rcu_read_lock in rmnet_force_unassociate_device() · c026d970
      Taehee Yoo 提交于
      The notifier_call() of the slave interface removes rmnet interface with
      unregister_netdevice_queue().
      But, before calling unregister_netdevice_queue(), it acquires
      rcu readlock.
      In the RCU critical section, sleeping isn't be allowed.
      But, unregister_netdevice_queue() internally calls synchronize_net(),
      which would sleep.
      So, suspicious RCU usage warning occurs.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link set dummy1 master rmnet0
          ip link del dummy0
      
      Splat looks like:
      [   79.639245][ T1195] =============================
      [   79.640134][ T1195] WARNING: suspicious RCU usage
      [   79.640852][ T1195] 5.6.0-rc1+ #447 Not tainted
      [   79.641657][ T1195] -----------------------------
      [   79.642472][ T1195] ./include/linux/rcupdate.h:273 Illegal context switch in RCU read-side critical section!
      [   79.644043][ T1195]
      [   79.644043][ T1195] other info that might help us debug this:
      [   79.644043][ T1195]
      [   79.645682][ T1195]
      [   79.645682][ T1195] rcu_scheduler_active = 2, debug_locks = 1
      [   79.646980][ T1195] 2 locks held by ip/1195:
      [   79.647629][ T1195]  #0: ffffffffa3cf64f0 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x457/0x890
      [   79.649312][ T1195]  #1: ffffffffa39256c0 (rcu_read_lock){....}, at: rmnet_config_notify_cb+0xf0/0x590 [rmnet]
      [   79.651717][ T1195]
      [   79.651717][ T1195] stack backtrace:
      [   79.652650][ T1195] CPU: 3 PID: 1195 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   79.653702][ T1195] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   79.655037][ T1195] Call Trace:
      [   79.655560][ T1195]  dump_stack+0x96/0xdb
      [   79.656252][ T1195]  ___might_sleep+0x345/0x440
      [   79.656994][ T1195]  synchronize_net+0x18/0x30
      [   79.661132][ T1195]  netdev_rx_handler_unregister+0x40/0xb0
      [   79.666266][ T1195]  rmnet_unregister_real_device+0x42/0xb0 [rmnet]
      [   79.667211][ T1195]  rmnet_config_notify_cb+0x1f7/0x590 [rmnet]
      [   79.668121][ T1195]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   79.669166][ T1195]  ? rmnet_unregister_bridge.isra.6+0xf0/0xf0 [rmnet]
      [   79.670286][ T1195]  ? __module_text_address+0x13/0x140
      [   79.671139][ T1195]  notifier_call_chain+0x90/0x160
      [   79.671973][ T1195]  rollback_registered_many+0x660/0xcf0
      [   79.672893][ T1195]  ? netif_set_real_num_tx_queues+0x780/0x780
      [   79.675091][ T1195]  ? __lock_acquire+0xdfe/0x3de0
      [   79.675825][ T1195]  ? memset+0x1f/0x40
      [   79.676367][ T1195]  ? __nla_validate_parse+0x98/0x1ab0
      [   79.677290][ T1195]  unregister_netdevice_many.part.133+0x13/0x1b0
      [   79.678163][ T1195]  rtnl_delete_link+0xbc/0x100
      [ ... ]
      
      Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c026d970
    • T
      net: rmnet: fix suspicious RCU usage · 102210f7
      Taehee Yoo 提交于
      rmnet_get_port() internally calls rcu_dereference_rtnl(),
      which checks RTNL.
      But rmnet_get_port() could be called by packet path.
      The packet path is not protected by RTNL.
      So, the suspicious RCU usage problem occurs.
      
      Test commands:
          modprobe rmnet
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link set veth1 netns nst
          ip link add rmnet0 link veth0 type rmnet mux_id 1
          ip netns exec nst ip link add rmnet1 link veth1 type rmnet mux_id 1
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set rmnet1 up
          ip netns exec nst ip a a 192.168.100.2/24 dev rmnet1
          ip link set veth0 up
          ip link set rmnet0 up
          ip a a 192.168.100.1/24 dev rmnet0
          ping 192.168.100.2
      
      Splat looks like:
      [  146.630958][ T1174] WARNING: suspicious RCU usage
      [  146.631735][ T1174] 5.6.0-rc1+ #447 Not tainted
      [  146.632387][ T1174] -----------------------------
      [  146.633151][ T1174] drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:386 suspicious rcu_dereference_check() !
      [  146.634742][ T1174]
      [  146.634742][ T1174] other info that might help us debug this:
      [  146.634742][ T1174]
      [  146.645992][ T1174]
      [  146.645992][ T1174] rcu_scheduler_active = 2, debug_locks = 1
      [  146.646937][ T1174] 5 locks held by ping/1174:
      [  146.647609][ T1174]  #0: ffff8880c31dea70 (sk_lock-AF_INET){+.+.}, at: raw_sendmsg+0xab8/0x2980
      [  146.662463][ T1174]  #1: ffffffff93925660 (rcu_read_lock_bh){....}, at: ip_finish_output2+0x243/0x2150
      [  146.671696][ T1174]  #2: ffffffff93925660 (rcu_read_lock_bh){....}, at: __dev_queue_xmit+0x213/0x2940
      [  146.673064][ T1174]  #3: ffff8880c19ecd58 (&dev->qdisc_running_key#7){+...}, at: ip_finish_output2+0x714/0x2150
      [  146.690358][ T1174]  #4: ffff8880c5796898 (&dev->qdisc_xmit_lock_key#3){+.-.}, at: sch_direct_xmit+0x1e2/0x1020
      [  146.699875][ T1174]
      [  146.699875][ T1174] stack backtrace:
      [  146.701091][ T1174] CPU: 0 PID: 1174 Comm: ping Not tainted 5.6.0-rc1+ #447
      [  146.705215][ T1174] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  146.706565][ T1174] Call Trace:
      [  146.707102][ T1174]  dump_stack+0x96/0xdb
      [  146.708007][ T1174]  rmnet_get_port.part.9+0x76/0x80 [rmnet]
      [  146.709233][ T1174]  rmnet_egress_handler+0x107/0x420 [rmnet]
      [  146.710492][ T1174]  ? sch_direct_xmit+0x1e2/0x1020
      [  146.716193][ T1174]  rmnet_vnd_start_xmit+0x3d/0xa0 [rmnet]
      [  146.717012][ T1174]  dev_hard_start_xmit+0x160/0x740
      [  146.717854][ T1174]  sch_direct_xmit+0x265/0x1020
      [  146.718577][ T1174]  ? register_lock_class+0x14d0/0x14d0
      [  146.719429][ T1174]  ? dev_watchdog+0xac0/0xac0
      [  146.723738][ T1174]  ? __dev_queue_xmit+0x15fd/0x2940
      [  146.724469][ T1174]  ? lock_acquire+0x164/0x3b0
      [  146.725172][ T1174]  __dev_queue_xmit+0x20c7/0x2940
      [ ... ]
      
      Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      102210f7
    • T
      net: rmnet: fix NULL pointer dereference in rmnet_changelink() · 1eb1f43a
      Taehee Yoo 提交于
      In the rmnet_changelink(), it uses IFLA_LINK without checking
      NULL pointer.
      tb[IFLA_LINK] could be NULL pointer.
      So, NULL-ptr-deref could occur.
      
      rmnet already has a lower interface (real_dev).
      So, after this patch, rmnet_changelink() does not use IFLA_LINK anymore.
      
      Test commands:
          modprobe rmnet
          ip link add dummy0 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link set rmnet0 type rmnet mux_id 2
      
      Splat looks like:
      [   90.578726][ T1131] general protection fault, probably for non-canonical address 0xdffffc0000000000I
      [   90.581121][ T1131] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      [   90.582380][ T1131] CPU: 2 PID: 1131 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   90.584285][ T1131] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   90.587506][ T1131] RIP: 0010:rmnet_changelink+0x5a/0x8a0 [rmnet]
      [   90.588546][ T1131] Code: 83 ec 20 48 c1 ea 03 80 3c 02 00 0f 85 6f 07 00 00 48 8b 5e 28 48 b8 00 00 00 00 00 0
      [   90.591447][ T1131] RSP: 0018:ffff8880ce78f1b8 EFLAGS: 00010247
      [   90.592329][ T1131] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff8880ce78f8b0
      [   90.593253][ T1131] RDX: 0000000000000000 RSI: ffff8880ce78f4a0 RDI: 0000000000000004
      [   90.594058][ T1131] RBP: ffff8880cf543e00 R08: 0000000000000002 R09: 0000000000000002
      [   90.594859][ T1131] R10: ffffffffc0586a40 R11: 0000000000000000 R12: ffff8880ca47c000
      [   90.595690][ T1131] R13: ffff8880ca47c000 R14: ffff8880cf545000 R15: 0000000000000000
      [   90.596553][ T1131] FS:  00007f21f6c7e0c0(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000
      [   90.597504][ T1131] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   90.599418][ T1131] CR2: 0000556e413db458 CR3: 00000000c917a002 CR4: 00000000000606e0
      [   90.600289][ T1131] Call Trace:
      [   90.600631][ T1131]  __rtnl_newlink+0x922/0x1270
      [   90.601194][ T1131]  ? lock_downgrade+0x6e0/0x6e0
      [   90.601724][ T1131]  ? rtnl_link_unregister+0x220/0x220
      [   90.602309][ T1131]  ? lock_acquire+0x164/0x3b0
      [   90.602784][ T1131]  ? is_bpf_image_address+0xff/0x1d0
      [   90.603331][ T1131]  ? rtnl_newlink+0x4c/0x90
      [   90.603810][ T1131]  ? kernel_text_address+0x111/0x140
      [   90.604419][ T1131]  ? __kernel_text_address+0xe/0x30
      [   90.604981][ T1131]  ? unwind_get_return_address+0x5f/0xa0
      [   90.605616][ T1131]  ? create_prof_cpu_mask+0x20/0x20
      [   90.606304][ T1131]  ? arch_stack_walk+0x83/0xb0
      [   90.606985][ T1131]  ? stack_trace_save+0x82/0xb0
      [   90.607656][ T1131]  ? stack_trace_consume_entry+0x160/0x160
      [   90.608503][ T1131]  ? deactivate_slab.isra.78+0x2c5/0x800
      [   90.609336][ T1131]  ? kasan_unpoison_shadow+0x30/0x40
      [   90.610096][ T1131]  ? kmem_cache_alloc_trace+0x135/0x350
      [   90.610889][ T1131]  ? rtnl_newlink+0x4c/0x90
      [   90.611512][ T1131]  rtnl_newlink+0x65/0x90
      [ ... ]
      
      Fixes: 23790ef1 ("net: qualcomm: rmnet: Allow to configure flags for existing devices")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1eb1f43a
    • T
      net: rmnet: fix NULL pointer dereference in rmnet_newlink() · 93b5cbfa
      Taehee Yoo 提交于
      rmnet registers IFLA_LINK interface as a lower interface.
      But, IFLA_LINK could be NULL.
      In the current code, rmnet doesn't check IFLA_LINK.
      So, panic would occur.
      
      Test commands:
          modprobe rmnet
          ip link add rmnet0 type rmnet mux_id 1
      
      Splat looks like:
      [   36.826109][ T1115] general protection fault, probably for non-canonical address 0xdffffc0000000000I
      [   36.838817][ T1115] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
      [   36.839908][ T1115] CPU: 1 PID: 1115 Comm: ip Not tainted 5.6.0-rc1+ #447
      [   36.840569][ T1115] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   36.841408][ T1115] RIP: 0010:rmnet_newlink+0x54/0x510 [rmnet]
      [   36.841986][ T1115] Code: 83 ec 18 48 c1 e9 03 80 3c 01 00 0f 85 d4 03 00 00 48 8b 6a 28 48 b8 00 00 00 00 00 c
      [   36.843923][ T1115] RSP: 0018:ffff8880b7e0f1c0 EFLAGS: 00010247
      [   36.844756][ T1115] RAX: dffffc0000000000 RBX: ffff8880d14cca00 RCX: 1ffff11016fc1e99
      [   36.845859][ T1115] RDX: 0000000000000000 RSI: ffff8880c3d04000 RDI: 0000000000000004
      [   36.846961][ T1115] RBP: 0000000000000000 R08: ffff8880b7e0f8b0 R09: ffff8880b6ac2d90
      [   36.848020][ T1115] R10: ffffffffc0589a40 R11: ffffed1016d585b7 R12: ffffffff88ceaf80
      [   36.848788][ T1115] R13: ffff8880c3d04000 R14: ffff8880b7e0f8b0 R15: ffff8880c3d04000
      [   36.849546][ T1115] FS:  00007f50ab3360c0(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [   36.851784][ T1115] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   36.852422][ T1115] CR2: 000055871afe5ab0 CR3: 00000000ae246001 CR4: 00000000000606e0
      [   36.853181][ T1115] Call Trace:
      [   36.853514][ T1115]  __rtnl_newlink+0xbdb/0x1270
      [   36.853967][ T1115]  ? lock_downgrade+0x6e0/0x6e0
      [   36.854420][ T1115]  ? rtnl_link_unregister+0x220/0x220
      [   36.854936][ T1115]  ? lock_acquire+0x164/0x3b0
      [   36.855376][ T1115]  ? is_bpf_image_address+0xff/0x1d0
      [   36.855884][ T1115]  ? rtnl_newlink+0x4c/0x90
      [   36.856304][ T1115]  ? kernel_text_address+0x111/0x140
      [   36.856857][ T1115]  ? __kernel_text_address+0xe/0x30
      [   36.857440][ T1115]  ? unwind_get_return_address+0x5f/0xa0
      [   36.858063][ T1115]  ? create_prof_cpu_mask+0x20/0x20
      [   36.858644][ T1115]  ? arch_stack_walk+0x83/0xb0
      [   36.859171][ T1115]  ? stack_trace_save+0x82/0xb0
      [   36.859710][ T1115]  ? stack_trace_consume_entry+0x160/0x160
      [   36.860357][ T1115]  ? deactivate_slab.isra.78+0x2c5/0x800
      [   36.860928][ T1115]  ? kasan_unpoison_shadow+0x30/0x40
      [   36.861520][ T1115]  ? kmem_cache_alloc_trace+0x135/0x350
      [   36.862125][ T1115]  ? rtnl_newlink+0x4c/0x90
      [   36.864073][ T1115]  rtnl_newlink+0x65/0x90
      [ ... ]
      
      Fixes: ceed73a2 ("drivers: net: ethernet: qualcomm: rmnet: Initial implementation")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93b5cbfa
    • R
      net: phy: marvell: don't interpret PHY status unless resolved · b82cf17f
      Russell King 提交于
      Don't attempt to interpret the PHY specific status register unless
      the PHY is indicating that the resolution is valid.
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b82cf17f
    • J
      mlx5: register lag notifier for init network namespace only · e387f7d5
      Jiri Pirko 提交于
      The current code causes problems when the unregistering netdevice could
      be different then the registering one.
      
      Since the check in mlx5_lag_netdev_event() does not allow any other
      network namespace anyway, fix this by registerting the lag notifier
      per init network namespace only.
      
      Fixes: d48834f9 ("mlx5: Use dev_net netdevice notifier registrations")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Tested-by: NAya Levin <ayal@mellanox.com>
      Acked-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e387f7d5
    • L
      hinic: fix a bug of rss configuration · 386d4716
      Luo bin 提交于
      should use real receive queue number to configure hw rss
      indirect table rather than maximal queue number
      Signed-off-by: NLuo bin <luobin9@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      386d4716
    • L
      hinic: fix a bug of setting hw_ioctxt · d2ed69ce
      Luo bin 提交于
      a reserved field is used to signify prime physical function index
      in the latest firmware version, so we must assign a value to it
      correctly
      Signed-off-by: NLuo bin <luobin9@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2ed69ce
    • L
      hinic: fix a irq affinity bug · 0bff777b
      Luo bin 提交于
      can not use a local variable as an input parameter of
      irq_set_affinity_hint
      Signed-off-by: NLuo bin <luobin9@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bff777b
    • B
      nvme-pci: Hold cq_poll_lock while completing CQEs · 9515743b
      Bijan Mottahedeh 提交于
      Completions need to consumed in the same order the controller submitted
      them, otherwise future completion entries may overwrite ones we haven't
      handled yet. Hold the nvme queue's poll lock while completing new CQEs to
      prevent another thread from freeing command tags for reuse out-of-order.
      
      Fixes: dabcefab ("nvme: provide optimized poll function for separate poll queues")
      Signed-off-by: NBijan Mottahedeh <bijan.mottahedeh@oracle.com>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      9515743b
  5. 27 2月, 2020 11 次提交
  6. 26 2月, 2020 3 次提交