1. 22 Oct, 2020 7 commits
    • Lijun Pan's avatar
      ibmvnic: save changed mac address to adapter->mac_addr · d9b0e599
      Lijun Pan authored
      After mac address change request completes successfully, the new mac
      address need to be saved to adapter->mac_addr as well as
      netdev->dev_addr. Otherwise, adapter->mac_addr still holds old
      data.
      
      Fixes: 62740e97 ("net/ibmvnic: Update MAC address settings after adapter reset")
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Link: https://lore.kernel.org/r/20201020223919.46106-1-ljp@linux.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d9b0e599
    • Matthieu Baerts's avatar
      selftests: mptcp: depends on built-in IPv6 · 287d3540
      Matthieu Baerts authored
      Recently, CONFIG_MPTCP_IPV6 no longer selects CONFIG_IPV6. As a
      consequence, if CONFIG_MPTCP_IPV6=y is added to the kconfig, it will no
      longer ensure CONFIG_IPV6=y. If it is not enabled, CONFIG_MPTCP_IPV6
      will stay disabled and selftests will fail.
      
      We also need CONFIG_IPV6 to be built-in. For more details, please see
      commit 0ed37ac5 ("mptcp: depends on IPV6 but not as a module").
      
      Note that 'make kselftest-merge' will take all 'config' files found in
      'tools/testsing/selftests'. Because some of them already set
      CONFIG_IPV6=y, MPTCP selftests were still passing. But they will fail if
      MPTCP selftests are launched manually after having executed this command
      to prepare the kernel config:
      
        ./scripts/kconfig/merge_config.sh -m .config \
            ./tools/testing/selftests/net/mptcp/config
      
      Fixes: 010b430d ("mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting it")
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Link: https://lore.kernel.org/r/20201021155549.933731-1-matthieu.baerts@tessares.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      287d3540
    • Michael S. Tsirkin's avatar
      Revert "virtio-net: ethtool configurable RXCSUM" · cf8691cb
      Michael S. Tsirkin authored
      This reverts commit 3618ad2a.
      
      When control vq is not negotiated, that commit causes a crash:
      
      [   72.229171] kernel BUG at drivers/net/virtio_net.c:1667!
      [   72.230266] invalid opcode: 0000 [#1] PREEMPT SMP
      [   72.231172] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc8-02934-g3618ad2a #1
      [   72.231172] EIP: virtnet_send_command+0x120/0x140
      [   72.231172] Code: 00 0f 94 c0 8b 7d f0 65 33 3d 14 00 00 00 75 1c 8d 65 f4 5b 5e 5f 5d c3 66 90 be 01 00 00 00 e9 6e ff ff ff 8d b6 00
      +00 00 00 <0f> 0b e8 d9 bb 82 00 eb 17 8d b4 26 00 00 00 00 8d b4 26 00 00 00
      [   72.231172] EAX: 0000000d EBX: f72895c0 ECX: 00000017 EDX: 00000011
      [   72.231172] ESI: f7197800 EDI: ed69bd00 EBP: ed69bcf4 ESP: ed69bc98
      [   72.231172] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
      [   72.231172] CR0: 80050033 CR2: 00000000 CR3: 02c84000 CR4: 000406f0
      [   72.231172] Call Trace:
      [   72.231172]  ? __virt_addr_valid+0x45/0x60
      [   72.231172]  ? ___cache_free+0x51f/0x760
      [   72.231172]  ? kobject_uevent_env+0xf4/0x560
      [   72.231172]  virtnet_set_guest_offloads+0x4d/0x80
      [   72.231172]  virtnet_set_features+0x85/0x120
      [   72.231172]  ? virtnet_set_guest_offloads+0x80/0x80
      [   72.231172]  __netdev_update_features+0x27a/0x8e0
      [   72.231172]  ? kobject_uevent+0xa/0x20
      [   72.231172]  ? netdev_register_kobject+0x12c/0x160
      [   72.231172]  register_netdevice+0x4fe/0x740
      [   72.231172]  register_netdev+0x1c/0x40
      [   72.231172]  virtnet_probe+0x728/0xb60
      [   72.231172]  ? _raw_spin_unlock+0x1d/0x40
      [   72.231172]  ? virtio_vdpa_get_status+0x1c/0x20
      [   72.231172]  virtio_dev_probe+0x1c6/0x271
      [   72.231172]  really_probe+0x195/0x2e0
      [   72.231172]  driver_probe_device+0x26/0x60
      [   72.231172]  device_driver_attach+0x49/0x60
      [   72.231172]  __driver_attach+0x46/0xc0
      [   72.231172]  ? device_driver_attach+0x60/0x60
      [   72.231172]  bus_add_driver+0x197/0x1c0
      [   72.231172]  driver_register+0x66/0xc0
      [   72.231172]  register_virtio_driver+0x1b/0x40
      [   72.231172]  virtio_net_driver_init+0x61/0x86
      [   72.231172]  ? veth_init+0x14/0x14
      [   72.231172]  do_one_initcall+0x76/0x2e4
      [   72.231172]  ? rdinit_setup+0x2a/0x2a
      [   72.231172]  do_initcalls+0xb2/0xd5
      [   72.231172]  kernel_init_freeable+0x14f/0x179
      [   72.231172]  ? rest_init+0x100/0x100
      [   72.231172]  kernel_init+0xd/0xe0
      [   72.231172]  ret_from_fork+0x1c/0x30
      [   72.231172] Modules linked in:
      [   72.269563] ---[ end trace a6ebc4afea0e6cb1 ]---
      
      The reason is that virtnet_set_features now calls virtnet_set_guest_offloads
      unconditionally, it used to only call it when there is something
      to configure.
      
      If device does not have a control vq, everything breaks.
      
      Revert the original commit for now.
      
      Cc: Tonghao Zhang <xiangxia.m.yue@gmail.com>
      Fixes: 3618ad2a ("virtio-net: ethtool configurable RXCSUM")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Link: https://lore.kernel.org/r/20201021142944.13615-1-mst@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      cf8691cb
    • Di Zhu's avatar
      rtnetlink: fix data overflow in rtnl_calcit() · ebfe3c51
      Di Zhu authored
      "ip addr show" command execute error when we have a physical
      network card with a large number of VFs
      
      The return value of if_nlmsg_size() in rtnl_calcit() will exceed
      range of u16 data type when any network cards has a larger number of
      VFs. rtnl_vfinfo_size() will significant increase needed dump size when
      the value of num_vfs is larger.
      
      Eventually we get a wrong value of min_ifinfo_dump_size because of overflow
      which decides the memory size needed by netlink dump and netlink_dump()
      will return -EMSGSIZE because of not enough memory was allocated.
      
      So fix it by promoting  min_dump_alloc data type to u32 to
      avoid whole netlink message size overflow and it's also align
      with the data type of struct netlink_callback{}.min_dump_alloc
      which is assigned by return value of rtnl_calcit()
      Signed-off-by: default avatarDi Zhu <zhudi21@huawei.com>
      Link: https://lore.kernel.org/r/20201021020053.1401-1-zhudi21@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ebfe3c51
    • Bartosz Golaszewski's avatar
      net: ethernet: mtk-star-emac: select REGMAP_MMIO · 5403caf2
      Bartosz Golaszewski authored
      The driver depends on mmio regmap API but doesn't select the appropriate
      Kconfig option. This fixes it.
      
      Fixes: 8c7bd5a4 ("net: ethernet: mtk-star-emac: new driver")
      Signed-off-by: default avatarBartosz Golaszewski <bgolaszewski@baylibre.com>
      Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.plSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5403caf2
    • Xie He's avatar
      net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setup · 5fce1e43
      Xie He authored
      This driver calls ether_setup to set up the network device.
      The ether_setup function would add the IFF_TX_SKB_SHARING flag to the
      device. This flag indicates that it is safe to transmit shared skbs to
      the device.
      
      However, this is not true. This driver may pad the frame (in eth_tx)
      before transmission, so the skb may be modified.
      
      Fixes: 550fd08c ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared")
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5fce1e43
    • Xie He's avatar
      net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device · 01c4ceae
      Xie He authored
      The hdlc_rcv function is used as hdlc_packet_type.func to process any
      skb received in the kernel with skb->protocol == htons(ETH_P_HDLC).
      The purpose of this function is to provide second-stage processing for
      skbs not assigned a "real" L3 skb->protocol value in the first stage.
      
      This function assumes the device from which the skb is received is an
      HDLC device (a device created by this module). It assumes that
      netdev_priv(dev) returns a pointer to "struct hdlc_device".
      
      However, it is possible that some driver in the kernel (not necessarily
      in our control) submits a received skb with skb->protocol ==
      htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would
      still be received by hdlc_rcv. This will cause problems.
      
      hdlc_rcv should be able to recognize and drop invalid skbs. It should
      first make sure "dev" is actually an HDLC device, before starting its
      processing. This patch adds this check to hdlc_rcv.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      01c4ceae
  2. 21 Oct, 2020 16 commits
  3. 20 Oct, 2020 13 commits
  4. 19 Oct, 2020 1 commit
  5. 18 Oct, 2020 3 commits
    • Taehee Yoo's avatar
      net: core: use list_del_init() instead of list_del() in netdev_run_todo() · 0e8b8d6a
      Taehee Yoo authored
      dev->unlink_list is reused unless dev is deleted.
      So, list_del() should not be used.
      Due to using list_del(), dev->unlink_list can't be reused so that
      dev->nested_level update logic doesn't work.
      In order to fix this bug, list_del_init() should be used instead
      of list_del().
      
      Test commands:
          ip link add bond0 type bond
          ip link add bond1 type bond
          ip link set bond0 master bond1
          ip link set bond0 nomaster
          ip link set bond1 master bond0
          ip link set bond1 nomaster
      
      Splat looks like:
      [  255.750458][ T1030] ============================================
      [  255.751967][ T1030] WARNING: possible recursive locking detected
      [  255.753435][ T1030] 5.9.0-rc8+ #772 Not tainted
      [  255.754553][ T1030] --------------------------------------------
      [  255.756047][ T1030] ip/1030 is trying to acquire lock:
      [  255.757304][ T1030] ffff88811782a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: dev_mc_sync_multiple+0xc2/0x150
      [  255.760056][ T1030]
      [  255.760056][ T1030] but task is already holding lock:
      [  255.761862][ T1030] ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.764581][ T1030]
      [  255.764581][ T1030] other info that might help us debug this:
      [  255.766645][ T1030]  Possible unsafe locking scenario:
      [  255.766645][ T1030]
      [  255.768566][ T1030]        CPU0
      [  255.769415][ T1030]        ----
      [  255.770259][ T1030]   lock(&dev_addr_list_lock_key/1);
      [  255.771629][ T1030]   lock(&dev_addr_list_lock_key/1);
      [  255.772994][ T1030]
      [  255.772994][ T1030]  *** DEADLOCK ***
      [  255.772994][ T1030]
      [  255.775091][ T1030]  May be due to missing lock nesting notation
      [  255.775091][ T1030]
      [  255.777182][ T1030] 2 locks held by ip/1030:
      [  255.778299][ T1030]  #0: ffffffffb1f63250 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x2e4/0x8b0
      [  255.780600][ T1030]  #1: ffff88811130a280 (&dev_addr_list_lock_key/1){+...}-{2:2}, at: bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.783411][ T1030]
      [  255.783411][ T1030] stack backtrace:
      [  255.784874][ T1030] CPU: 7 PID: 1030 Comm: ip Not tainted 5.9.0-rc8+ #772
      [  255.786595][ T1030] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      [  255.789030][ T1030] Call Trace:
      [  255.789850][ T1030]  dump_stack+0x99/0xd0
      [  255.790882][ T1030]  __lock_acquire.cold.71+0x166/0x3cc
      [  255.792285][ T1030]  ? register_lock_class+0x1a30/0x1a30
      [  255.793619][ T1030]  ? rcu_read_lock_sched_held+0x91/0xc0
      [  255.794963][ T1030]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [  255.796246][ T1030]  lock_acquire+0x1b8/0x850
      [  255.797332][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
      [  255.798624][ T1030]  ? bond_enslave+0x3d4d/0x43e0 [bonding]
      [  255.800039][ T1030]  ? check_flags+0x50/0x50
      [  255.801143][ T1030]  ? lock_contended+0xd80/0xd80
      [  255.802341][ T1030]  _raw_spin_lock_nested+0x2e/0x70
      [  255.803592][ T1030]  ? dev_mc_sync_multiple+0xc2/0x150
      [  255.804897][ T1030]  dev_mc_sync_multiple+0xc2/0x150
      [  255.806168][ T1030]  bond_enslave+0x3d58/0x43e0 [bonding]
      [  255.807542][ T1030]  ? __lock_acquire+0xe53/0x51b0
      [  255.808824][ T1030]  ? bond_update_slave_arr+0xdc0/0xdc0 [bonding]
      [  255.810451][ T1030]  ? check_chain_key+0x236/0x5e0
      [  255.811742][ T1030]  ? mutex_is_locked+0x13/0x50
      [  255.812910][ T1030]  ? rtnl_is_locked+0x11/0x20
      [  255.814061][ T1030]  ? netdev_master_upper_dev_get+0xf/0x120
      [  255.815553][ T1030]  do_setlink+0x94c/0x3040
      [ ... ]
      
      Reported-by: syzbot+4a0f7bc34e3997a6c7df@syzkaller.appspotmail.com
      Fixes: 1fc70edb ("net: core: add nested_level variable in net_device")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Link: https://lore.kernel.org/r/20201015162606.9377-1-ap420073@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0e8b8d6a
    • Jakub Kicinski's avatar
      ixgbe: fix probing of multi-port devices with one MDIO · bd7f14df
      Jakub Kicinski authored
      Ian reports that after upgrade from v5.8.14 to v5.9 only one
      of his 4 ixgbe netdevs appear in the system.
      
      Quoting the comment on ixgbe_x550em_a_has_mii():
       * Returns true if hw points to lowest numbered PCI B:D.F x550_em_a device in
       * the SoC.  There are up to 4 MACs sharing a single MDIO bus on the x550em_a,
       * but we only want to register one MDIO bus.
      
      This matches the symptoms, since the return value from
      ixgbe_mii_bus_init() is no longer ignored we need to handle
      the higher ports of x550em without an error.
      
      Fixes: 09ef193f ("net: ethernet: ixgbe: check the return value of ixgbe_mii_bus_init()")
      Reported-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
      Tested-by: default avatarIan Kumlien <ian.kumlien@gmail.com>
      Acked-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Link: https://lore.kernel.org/r/20201016232006.3352947-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bd7f14df
    • Anant Thazhemadam's avatar
      net: usb: rtl8150: don't incorrectly assign random MAC addresses · 60f1626f
      Anant Thazhemadam authored
      In set_ethernet_addr(), if get_registers() succeeds, the ethernet address
      that was read must be copied over. Otherwise, a random ethernet address
      must be assigned.
      
      get_registers() returns 0 if successful, and negative error number
      otherwise. However, in set_ethernet_addr(), this return value is
      incorrectly checked.
      
      Since this return value will never be equal to sizeof(node_id), a
      random MAC address will always be generated and assigned to the
      device; even in cases when get_registers() is successful.
      
      Correctly modifying the condition that checks if get_registers() was
      successful or not fixes this problem, and copies the ethernet address
      appropriately.
      
      Fixes: b2a0f274 ("net: rtl8150: Use the new usb control message API.")
      Signed-off-by: default avatarAnant Thazhemadam <anant.thazhemadam@gmail.com>
      Link: https://lore.kernel.org/r/20201011173030.141582-1-anant.thazhemadam@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      60f1626f