1. 18 Jan, 2019 8 commits
    • Ido Schimmel's avatar
      mlxsw: pci: Ring CQ's doorbell before RDQ's · c9ebea04
      Ido Schimmel authored
      When a packet should be trapped to the CPU the device consumes a WQE
      (work queue element) from an RDQ (receive descriptor queue) and copies
      the packet to the address specified in the WQE. The device then tries to
      post a CQE (completion queue element) that contains various metadata
      (e.g., ingress port) about the packet to a CQ (completion queue).
      In case the device managed to consume a WQE, but did not manage to post
      the corresponding CQE, it will get stuck. This unlikely situation can be
      triggered due to the scheme the driver is currently using to process
      The driver will consume up to 512 CQEs at a time and after processing
      each corresponding WQE it will ring the RDQ's doorbell, letting the
      device know that a new WQE was posted for it to consume. Only after
      processing all the CQEs (up to 512), the driver will ring the CQ's
      doorbell, letting the device know that new ones can be posted.
      Fix this by having the driver ring the CQ's doorbell for every processed
      CQE, but before ringing the RDQ's doorbell. This guarantees that
      whenever we post a new WQE, there is a corresponding CQE available. Copy
      the currently processed CQE to prevent the device from overwriting it
      with a new CQE after ringing the doorbell.
      Note that the driver still arms the CQ only after processing all the
      pending CQEs, so that interrupts for this CQ will only be delivered
      after the driver finished its processing.
      Before commit 8404f6f2 ("mlxsw: pci: Allow to use CQEs of version 1
      and version 2") the issue was virtually impossible to trigger since the
      number of CQEs was twice the number of WQEs and the number of CQEs
      processed at a time was equal to the number of available WQEs.
      Fixes: 8404f6f2
       ("mlxsw: pci: Allow to use CQEs of version 1 and version 2")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Reported-by: default avatarSemion Lisyansky <semionl@mellanox.com>
      Tested-by: default avatarSemion Lisyansky <semionl@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jonathan Neuschäfer's avatar
      net: Fix typo in NET_FAILOVER help text · 9437b629
      Jonathan Neuschäfer authored
      "also enables" should not be spelled as one word.
      Fixes: cfc80d9a
       ("net: Introduce net_failover driver")
      Signed-off-by: default avatarJonathan Neuschäfer <j.neuschaefer@gmx.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Ross Lagerwall's avatar
      net: Fix usage of pskb_trim_rcsum · 6c57f045
      Ross Lagerwall authored
      In certain cases, pskb_trim_rcsum() may change skb pointers.
      Reinitialize header pointers afterwards to avoid potential
      use-after-frees. Add a note in the documentation of
      pskb_trim_rcsum(). Found by KASAN.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Thomas Petazzoni's avatar
      net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling · e40e2a2e
      Thomas Petazzoni authored
      The current code in __mdiobus_register() doesn't properly handle
      failures returned by the devm_gpiod_get_optional() call: it returns
      immediately, without unregistering the device that was added by the
      call to device_register() earlier in the function.
      This leaves a stale device, which then causes a NULL pointer
      dereference in the code that handles deferred probing:
      [    1.489982] Unable to handle kernel NULL pointer dereference at virtual address 00000074
      [    1.498110] pgd = (ptrval)
      [    1.500838] [00000074] *pgd=00000000
      [    1.504432] Internal error: Oops: 17 [#1] SMP ARM
      [    1.509133] Modules linked in:
      [    1.512192] CPU: 1 PID: 51 Comm: kworker/1:3 Not tainted 4.20.0-00039-g3b73a4cc8b3e-dirty #99
      [    1.520708] Hardware name: Xilinx Zynq Platform
      [    1.525261] Workqueue: events deferred_probe_work_func
      [    1.530403] PC is at klist_next+0x10/0xfc
      [    1.534403] LR is at device_for_each_child+0x40/0x94
      [    1.539361] pc : [<c0683fbc>]    lr : [<c0455d90>]    psr: 200e0013
      [    1.545628] sp : ceeefe68  ip : 00000001  fp : ffffe000
      [    1.550863] r10: 00000000  r9 : c0c66790  r8 : 00000000
      [    1.556079] r7 : c0457d44  r6 : 00000000  r5 : ceeefe8c  r4 : cfa2ec78
      [    1.562604] r3 : 00000064  r2 : c0457d44  r1 : ceeefe8c  r0 : 00000064
      [    1.569129] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [    1.576263] Control: 18c5387d  Table: 0ed7804a  DAC: 00000051
      [    1.582013] Process kworker/1:3 (pid: 51, stack limit = 0x(ptrval))
      [    1.588280] Stack: (0xceeefe68 to 0xceef0000)
      [    1.592630] fe60:                   cfa2ec78 c0c03c08 00000000 c0457d44 00000000 c0c66790
      [    1.600814] fe80: 00000000 c0455d90 ceeefeac 00000064 00000000 0d7a542e cee9d494 cfa2ec78
      [    1.608998] fea0: cfa2ec78 00000000 c0457d44 c0457d7c cee9d494 c0c03c08 00000000 c0455dac
      [    1.617182] fec0: cf98ba44 cf926a00 cee9d494 0d7a542e 00000000 cf935a10 cf935a10 cf935a10
      [    1.625366] fee0: c0c4e9b8 c0457d7c c0c4e80c 00000001 cf935a10 c0457df4 cf935a10 c0c4e99c
      [    1.633550] ff00: c0c4e99c c045a27c c0c4e9c4 ced63f80 cfde8a80 cfdebc00 00000000 c013893c
      [    1.641734] ff20: cfde8a80 cfde8a80 c07bd354 ced63f80 ced63f94 cfde8a80 00000008 c0c02d00
      [    1.649936] ff40: cfde8a98 cfde8a80 ffffe000 c0139a30 ffffe000 c0c6624a c07bd354 00000000
      [    1.658120] ff60: ffffe000 cee9e780 ceebfe00 00000000 ceeee000 ced63f80 c0139788 cf8cdea4
      [    1.666304] ff80: cee9e79c c013e598 00000001 ceebfe00 c013e44c 00000000 00000000 00000000
      [    1.674488] ffa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
      [    1.682671] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    1.690855] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
      [    1.699058] [<c0683fbc>] (klist_next) from [<c0455d90>] (device_for_each_child+0x40/0x94)
      [    1.707241] [<c0455d90>] (device_for_each_child) from [<c0457d7c>] (device_reorder_to_tail+0x38/0x88)
      [    1.716476] [<c0457d7c>] (device_reorder_to_tail) from [<c0455dac>] (device_for_each_child+0x5c/0x94)
      [    1.725692] [<c0455dac>] (device_for_each_child) from [<c0457d7c>] (device_reorder_to_tail+0x38/0x88)
      [    1.734927] [<c0457d7c>] (device_reorder_to_tail) from [<c0457df4>] (device_pm_move_to_tail+0x28/0x40)
      [    1.744235] [<c0457df4>] (device_pm_move_to_tail) from [<c045a27c>] (deferred_probe_work_func+0x58/0x8c)
      [    1.753746] [<c045a27c>] (deferred_probe_work_func) from [<c013893c>] (process_one_work+0x210/0x4fc)
      [    1.762888] [<c013893c>] (process_one_work) from [<c0139a30>] (worker_thread+0x2a8/0x5c0)
      [    1.771072] [<c0139a30>] (worker_thread) from [<c013e598>] (kthread+0x14c/0x154)
      [    1.778482] [<c013e598>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
      [    1.785689] Exception stack(0xceeeffb0 to 0xceeefff8)
      [    1.790739] ffa0:                                     00000000 00000000 00000000 00000000
      [    1.798923] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      [    1.807107] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
      [    1.813724] Code: e92d47f0 e1a05000 e8900048 e1a00003 (e5937010)
      [    1.819844] ---[ end trace 3c2c0c8b65399ec9 ]---
      The actual error that we had from devm_gpiod_get_optional() was
      -EPROBE_DEFER, due to the GPIO being provided by a driver that is
      probed later than the Ethernet controller driver.
      To fix this, we simply add the missing device_del() invocation in the
      error path.
      Fixes: 69226896
       ("mdio_bus: Issue GPIO RESET to PHYs")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@bootlin.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Yang Wei's avatar
      macvlan: replace kfree_skb by consume_skb for drop profiles · bf97403a
      Yang Wei authored
      Replace the kfree_skb() by consume_skb() to be drop monitor(dropwatch,
      perf) friendly.
      Signed-off-by: default avatarYang Wei <yang.wei9@zte.com.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Lendacky, Thomas's avatar
      amd-xgbe: Fix mdio access for non-zero ports and clause 45 PHYs · 5ab3121b
      Lendacky, Thomas authored
      The XGBE hardware has support for performing MDIO operations using an
      MDIO command request. The driver mistakenly uses the mdio port address
      as the MDIO command request device address instead of the MDIO command
      request port address. Additionally, the driver does not properly check
      for and create a clause 45 MDIO command.
      Check the supplied MDIO register to determine if the request is a clause
      45 operation (MII_ADDR_C45). For a clause 45 operation, extract the device
      address and register number from the supplied MDIO register and use them
      to set the MDIO command request device address and register number fields.
      For a clause 22 operation, the MDIO request device address is set to zero
      and the MDIO command request register number is set to the supplied MDIO
      register. In either case, the supplied MDIO port address is used as the
      MDIO command request port address.
      Fixes: 732f2ab7
       ("amd-xgbe: Add support for MDIO attached PHYs")
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Tested-by: default avatarShyam Sundar S K <Shyam-sundar.S-k@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Camelia Groza's avatar
      net: phy: add missing phy driver features · 40f89ebf
      Camelia Groza authored
      The phy drivers for CS4340 and TN2020 are missing their
      features attributes. Add them.
      Fixes: 719655a1
       ("net: phy: Replace phy driver features u32 with link_mode bitmap")
      Reported-by: default avatarScott Wood <oss@buserror.net>
      Signed-off-by: default avatarCamelia Groza <camelia.groza@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Madalin Bucur's avatar
      dpaa_eth: NETIF_F_LLTX requires to do our own update of trans_start · c6ddfb9a
      Madalin Bucur authored
      As txq_trans_update() only updates trans_start when the lock is held,
      trans_start does not get updated if NETIF_F_LLTX is declared.
      Signed-off-by: default avatarMadalin Bucur <madalin.bucur@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 17 Jan, 2019 1 commit
  3. 16 Jan, 2019 6 commits
  4. 15 Jan, 2019 2 commits
  5. 12 Jan, 2019 2 commits
  6. 11 Jan, 2019 5 commits
  7. 10 Jan, 2019 6 commits
    • Heiner Kallweit's avatar
      net: ethernet: mediatek: fix warning in phy_start_aneg · b19bce03
      Heiner Kallweit authored
      linux 5.0-rc1 shows following warning on bpi-r2/mt7623 bootup:
      [ 5.170597] WARNING: CPU: 3 PID: 1 at drivers/net/phy/phy.c:548 phy_start_aneg+0x110/0x144
      [ 5.178826] called from state READY
      [ 5.264111] [<c0629fd4>] (phy_start_aneg) from [<c0e3e720>] (mtk_init+0x414/0x47c)
      [ 5.271630] r7:df5f5eec r6:c0f08c48 r5:00000000 r4:dea67800
      [ 5.277256] [<c0e3e30c>] (mtk_init) from [<c07dabbc>] (register_netdevice+0x98/0x51c)
      [ 5.285035] r8:00000000 r7:00000000 r6:c0f97080 r5:c0f08c48 r4:dea67800
      [ 5.291693] [<c07dab24>] (register_netdevice) from [<c07db06c>] (register_netdev+0x2c/0x44)
      [ 5.299989] r8:00000000 r7:dea2e608 r6:deacea00 r5:dea2e604 r4:dea67800
      [ 5.306646] [<c07db040>] (register_netdev) from [<c06326d8>] (mtk_probe+0x668/0x7ac)
      [ 5.314336] r5:dea2e604 r4:dea2e040
      [ 5.317890] [<c0632070>] (mtk_probe) from [<c05a78fc>] (platform_drv_probe+0x58/0xa8)
      [ 5.325670] r10:c0f86bac r9:00000000 r8:c0fbe578 r7:00000000 r6:c0f86bac r5:00000000
      [ 5.333445] r4:deacea10
      [ 5.335963] [<c05a78a4>] (platform_drv_probe) from [<c05a5248>] (really_probe+0x2d8/0x424)
      maybe other boards using this generic driver are affected
      - phy_set_max_speed() is only needed if you want to reduce the
        max speed, typically if the PHY supports 1Gbps but the MAC
        supports 100Mbps only.
      - The pause parameters are autonegotiated. Except you have a specific
        need you normally don't need to manually fiddle with this.
      - phy_start_aneg() is called implicitly by the phylib state machine,
        you shouldn't call it manually except you have a good excuse.
      - netif_carrier_on/netif_carrier_off in mtk_phy_link_adjust() isn't
        needed. It's done by phy_link_change() in phylib.
      Signed-off-by: default avatarFrank Wunderlich <frank-w@public-files.de>
      Reviewed-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Acked-by: default avatarSean Wang <sean.wang@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Andrew Lunn's avatar
      net: dsa: mv88x6xxx: mv88e6390 errata · ea89098e
      Andrew Lunn authored
      The 6390 copper ports have an errata which require poking magic values
      into undocumented magic registers and then performing a software
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Willem de Bruijn's avatar
      bonding: update nest level on unlink · 001e465f
      Willem de Bruijn authored
      A network device stack with multiple layers of bonding devices can
      trigger a false positive lockdep warning. Adding lockdep nest levels
      fixes this. Update the level on both enslave and unlink, to avoid the
      following series of events ..
          ip netns add test
          ip netns exec test bash
          ip link set dev lo addr 00:11:22:33:44:55
          ip link set dev lo down
          ip link add dev bond1 type bond
          ip link add dev bond2 type bond
          ip link set dev lo master bond1
          ip link set dev bond1 master bond2
          ip link set dev bond1 nomaster
          ip link set dev bond2 master bond1
      .. from still generating a splat:
          [  193.652127] ======================================================
          [  193.658231] WARNING: possible circular locking dependency detected
          [  193.664350] 4.20.0 #8 Not tainted
          [  193.668310] ------------------------------------------------------
          [  193.674417] ip/15577 is trying to acquire lock:
          [  193.678897] 00000000a40e3b69 (&(&bond->stats_lock)->rlock#3/3){+.+.}, at: bond_get_stats+0x58/0x290
          [  193.687851]
          	       but task is already holding lock:
          [  193.693625] 00000000807b9d9f (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0x58/0x290
          [  193.851092]        lock_acquire+0xa7/0x190
          [  193.855138]        _raw_spin_lock_nested+0x2d/0x40
          [  193.859878]        bond_get_stats+0x58/0x290
          [  193.864093]        dev_get_stats+0x5a/0xc0
          [  193.868140]        bond_get_stats+0x105/0x290
          [  193.872444]        dev_get_stats+0x5a/0xc0
          [  193.876493]        rtnl_fill_stats+0x40/0x130
          [  193.880797]        rtnl_fill_ifinfo+0x6c5/0xdc0
          [  193.885271]        rtmsg_ifinfo_build_skb+0x86/0xe0
          [  193.890091]        rtnetlink_event+0x5b/0xa0
          [  193.894320]        raw_notifier_call_chain+0x43/0x60
          [  193.899225]        netdev_change_features+0x50/0xa0
          [  193.904044]        bond_compute_features.isra.46+0x1ab/0x270
          [  193.909640]        bond_enslave+0x141d/0x15b0
          [  193.913946]        do_set_master+0x89/0xa0
          [  193.918016]        do_setlink+0x37c/0xda0
          [  193.921980]        __rtnl_newlink+0x499/0x890
          [  193.926281]        rtnl_newlink+0x48/0x70
          [  193.930238]        rtnetlink_rcv_msg+0x171/0x4b0
          [  193.934801]        netlink_rcv_skb+0xd1/0x110
          [  193.939103]        rtnetlink_rcv+0x15/0x20
          [  193.943151]        netlink_unicast+0x3b5/0x520
          [  193.947544]        netlink_sendmsg+0x2fd/0x3f0
          [  193.951942]        sock_sendmsg+0x38/0x50
          [  193.955899]        ___sys_sendmsg+0x2ba/0x2d0
          [  193.960205]        __x64_sys_sendmsg+0xad/0x100
          [  193.964687]        do_syscall_64+0x5a/0x460
          [  193.968823]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Fixes: 7e2556e4
       ("bonding: avoid lockdep confusion in bond_get_stats()")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Colin Ian King's avatar
      net: cxgb4: fix various indentation issues · fd21c89b
      Colin Ian King authored
      There are some lines that have indentation issues, fix these.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Colin Ian King's avatar
      net: cxgb3: fix various indentation issues · 2acc0abc
      Colin Ian King authored
      There are handful of lines that have indentation issues, fix these.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Stanislav Fomichev's avatar
      tun: publish tfile after it's fully initialized · 0b7959b6
      Stanislav Fomichev authored
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000d1
      Call Trace:
       ? napi_gro_frags+0xa7/0x2c0
      I think there is a subtle race between sending a packet via tap and
      attaching it:
      CPU0:                    CPU1:
            rcu_assign_pointer(tfile->tun, tun);
                                       napi->skb = napi_alloc_skb
                napi->skb = NULL
                                    napi->skb is NULL here
      				  skb = napi->skb
      Move rcu_assign_pointer(tfile->tun) and rcu_assign_pointer(tun->tfiles) to
      be the last thing we do in tun_attach(); this should guarantee that when we
      call tun_get() we always get an initialized object.
      v2 changes:
      * remove extra napi_mutex locks/unlocks for napi operations
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Fixes: 90e33d45
       ("tun: enable napi_gro_frags() for TUN/TAP driver")
      Signed-off-by: default avatarStanislav Fomichev <sdf@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 08 Jan, 2019 10 commits