1. 06 Apr, 2022 13 commits
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue · 74edbe9e
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2022-04-05
      
      Maciej Fijalkowski says:
      
      We were solving issues around AF_XDP busy poll's not-so-usual scenarios,
      such as very big busy poll budgets applied to very small HW rings. This
      set carries the things that were found during that work that apply to
      net tree.
      
      One thing that was fixed for all in-tree ZC drivers was missing on ice
      side all the time - it's about syncing RCU before destroying XDP
      resources. Next one fixes the bit that is checked in ice_xsk_wakeup and
      third one avoids false setting of DD bits on Tx descriptors.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74edbe9e
    • Michael Walle's avatar
      net: phy: mscc-miim: reject clause 45 register accesses · 8d90991e
      Michael Walle authored
      The driver doesn't support clause 45 register access yet, but doesn't
      check if the access is a c45 one either. This leads to spurious register
      reads and writes. Add the check.
      
      Fixes: 542671fe ("net: phy: mscc-miim: Add MDIO driver")
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d90991e
    • David S. Miller's avatar
      Merge branch 'axienet-broken-link' · 9386d181
      David S. Miller authored
      Andy Chiu says:
      
      ====================
      Fix broken link on Xilinx's AXI Ethernet in SGMII mode
      
      The Ethernet driver use phy-handle to reference the PCS/PMA PHY. This
      could be a problem if one wants to configure an external PHY via phylink,
      since it use the same phandle to get the PHY. To fix this, introduce a
      dedicated pcs-handle to point to the PCS/PMA PHY and deprecate the use
      of pointing it with phy-handle. A similar use case of pcs-handle can be
      seen on dpaa2 as well.
      
      --- patch v5 ---
       - Re-apply the v4 patch on the net tree.
       - Describe the pcs-handle DT binding at ethernet-controller level.
      --- patch v6 ---
       - Remove "preferrably" to clearify usage of pcs_handle.
      --- patch v7 ---
       - Rebase the patch on latest net/master
      --- patch v8 ---
       - Rebase the patch on net-next/master
       - Add "reviewed-by" tag in PATCH 3/4: dt-bindings: net: add pcs-handle
         attribute
       - Remove "fix" tag in last commit message since this is not a critical
         bug and will not be back ported to stable.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9386d181
    • Andy Chiu's avatar
      net: axiemac: use a phandle to reference pcs_phy · 19c7a439
      Andy Chiu authored
      In some SGMII use cases where both a fixed link external PHY and the
      internal PCS/PMA PHY need to be configured, we should explicitly use a
      phandle "pcs-phy" to get the reference to the PCS/PMA PHY. Otherwise, the
      driver would use "phy-handle" in the DT as the reference to both the
      external and the internal PCS/PMA PHY.
      
      In other cases where the core is connected to a SFP cage, we could still
      point phy-handle to the intenal PCS/PMA PHY, and let the driver connect
      to the SFP module, if exist, via phylink.
      Signed-off-by: default avatarAndy Chiu <andy.chiu@sifive.com>
      Reviewed-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: default avatarRobert Hancock <robert.hancock@calian.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19c7a439
    • Andy Chiu's avatar
      dt-bindings: net: add pcs-handle attribute · dc48f04f
      Andy Chiu authored
      Document the new pcs-handle attribute to support connecting to an
      external PHY. For Xilinx's AXI Ethernet, this is used when the core
      operates in SGMII or 1000Base-X modes and links through the internal
      PCS/PMA PHY.
      Signed-off-by: default avatarAndy Chiu <andy.chiu@sifive.com>
      Reviewed-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc48f04f
    • Andy Chiu's avatar
      net: axienet: factor out phy_node in struct axienet_local · ab3a5d4c
      Andy Chiu authored
      the struct member `phy_node` of struct axienet_local is not used by the
      driver anymore after initialization. It might be a remnent of old code
      and could be removed.
      Signed-off-by: default avatarAndy Chiu <andy.chiu@sifive.com>
      Reviewed-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: default avatarRobert Hancock <robert.hancock@calian.com>
      Reviewed-by: default avatarRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab3a5d4c
    • Andy Chiu's avatar
      net: axienet: setup mdio unconditionally · d1c4f93e
      Andy Chiu authored
      The call to axienet_mdio_setup should not depend on whether "phy-node"
      pressents on the DT. Besides, since `lp->phy_node` is used if PHY is in
      SGMII or 100Base-X modes, move it into the if statement. And the next patch
      will remove `lp->phy_node` from driver's private structure and do an
      of_node_put on it right away after use since it is not used elsewhere.
      Signed-off-by: default avatarAndy Chiu <andy.chiu@sifive.com>
      Reviewed-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: default avatarRobert Hancock <robert.hancock@calian.com>
      Reviewed-by: default avatarRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1c4f93e
    • Taehee Yoo's avatar
      net: sfc: fix using uninitialized xdp tx_queue · fb5833d8
      Taehee Yoo authored
      In some cases, xdp tx_queue can get used before initialization.
      1. interface up/down
      2. ring buffer size change
      
      When CPU cores are lower than maximum number of channels of sfc driver,
      it creates new channels only for XDP.
      
      When an interface is up or ring buffer size is changed, all channels
      are initialized.
      But xdp channels are always initialized later.
      So, the below scenario is possible.
      Packets are received to rx queue of normal channels and it is acted
      XDP_TX and tx_queue of xdp channels get used.
      But these tx_queues are not initialized yet.
      If so, TX DMA or queue error occurs.
      
      In order to avoid this problem.
      1. initializes xdp tx_queues earlier than other rx_queue in
      efx_start_channels().
      2. checks whether tx_queue is initialized or not in efx_xdp_tx_buffers().
      
      Splat looks like:
         sfc 0000:08:00.1 enp8s0f1np1: TX queue 10 spurious TX completion id 250
         sfc 0000:08:00.1 enp8s0f1np1: resetting (RECOVER_OR_ALL)
         sfc 0000:08:00.1 enp8s0f1np1: MC command 0x80 inlen 100 failed rc=-22
         (raw=22) arg=789
         sfc 0000:08:00.1 enp8s0f1np1: has been disabled
      
      Fixes: f28100cb ("sfc: fix lack of XDP TX queues - error XDP TX failed (-22)")
      Acked-by: default avatarMartin Habets <habetsm.xilinx@gmail.com>
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb5833d8
    • Eric Dumazet's avatar
      rxrpc: fix a race in rxrpc_exit_net() · 1946014c
      Eric Dumazet authored
      Current code can lead to the following race:
      
      CPU0                                                 CPU1
      
      rxrpc_exit_net()
                                                           rxrpc_peer_keepalive_worker()
                                                             if (rxnet->live)
      
        rxnet->live = false;
        del_timer_sync(&rxnet->peer_keepalive_timer);
      
                                                                   timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
      
        cancel_work_sync(&rxnet->peer_keepalive_work);
      
      rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
      leading to use-after-free.
      
      syzbot report was:
      
      ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
      WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
      Modules linked in:
      CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c020 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Workqueue: netns cleanup_net
      RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
      Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
      RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
      RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
      RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
      RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
      R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
      R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
      FS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]
       debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023
       kfree+0xd6/0x310 mm/slab.c:3809
       ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176
       ops_free_list net/core/net_namespace.c:174 [inline]
       cleanup_net+0x591/0xb00 net/core/net_namespace.c:598
       process_one_work+0x996/0x1610 kernel/workqueue.c:2289
       worker_thread+0x665/0x1080 kernel/workqueue.c:2436
       kthread+0x2e9/0x3a0 kernel/kthread.c:376
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298
       </TASK>
      
      Fixes: ace45bec ("rxrpc: Fix firewall route keepalive")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Marc Dionne <marc.dionne@auristor.com>
      Cc: linux-afs@lists.infradead.org
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1946014c
    • Ilya Maximets's avatar
      net: openvswitch: fix leak of nested actions · 1f30fb91
      Ilya Maximets authored
      While parsing user-provided actions, openvswitch module may dynamically
      allocate memory and store pointers in the internal copy of the actions.
      So this memory has to be freed while destroying the actions.
      
      Currently there are only two such actions: ct() and set().  However,
      there are many actions that can hold nested lists of actions and
      ovs_nla_free_flow_actions() just jumps over them leaking the memory.
      
      For example, removal of the flow with the following actions will lead
      to a leak of the memory allocated by nf_ct_tmpl_alloc():
      
        actions:clone(ct(commit),0)
      
      Non-freed set() action may also leak the 'dst' structure for the
      tunnel info including device references.
      
      Under certain conditions with a high rate of flow rotation that may
      cause significant memory leak problem (2MB per second in reporter's
      case).  The problem is also hard to mitigate, because the user doesn't
      have direct control over the datapath flows generated by OVS.
      
      Fix that by iterating over all the nested actions and freeing
      everything that needs to be freed recursively.
      
      New build time assertion should protect us from this problem if new
      actions will be added in the future.
      
      Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all
      attributes has to be explicitly checked.  sample() and clone() actions
      are mixing extra attributes into the user-provided action list.  That
      prevents some code generalization too.
      
      Fixes: 34ae932a ("openvswitch: Make tunnel set action attach a metadata dst")
      Link: https://mail.openvswitch.org/pipermail/ovs-dev/2022-March/392922.htmlReported-by: default avatarStéphane Graber <stgraber@ubuntu.com>
      Signed-off-by: default avatarIlya Maximets <i.maximets@ovn.org>
      Acked-by: default avatarAaron Conole <aconole@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f30fb91
    • Andrew Lunn's avatar
      net: ethernet: mv643xx: Fix over zealous checking of_get_mac_address() · 11f8e7c1
      Andrew Lunn authored
      There is often not a MAC address available in an EEPROM accessible by
      Linux with Marvell devices. Instead the bootload has the MAC address
      and directly programs it into the hardware. So don't consider an error
      from of_get_mac_address() has fatal. However, the check was added for
      the case where there is a MAC address in an the EEPROM, but the EEPROM
      has not probed yet, and -EPROBE_DEFER is returned. In that case the
      error should be returned. So make the check specific to this error
      code.
      
      Cc: Mauri Sandberg <maukka@ext.kapsi.fi>
      Reported-by: default avatarThomas Walther <walther-it@gmx.de>
      Fixes: 42404d8f ("net: mv643xx_eth: process retval from of_get_mac_address")
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220405000404.3374734-1-andrew@lunn.chSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      11f8e7c1
    • Ilya Maximets's avatar
      net: openvswitch: don't send internal clone attribute to the userspace. · 3f2a3050
      Ilya Maximets authored
      'OVS_CLONE_ATTR_EXEC' is an internal attribute that is used for
      performance optimization inside the kernel.  It's added by the kernel
      while parsing user-provided actions and should not be sent during the
      flow dump as it's not part of the uAPI.
      
      The issue doesn't cause any significant problems to the ovs-vswitchd
      process, because reported actions are not really used in the
      application lifecycle and only supposed to be shown to a human via
      ovs-dpctl flow dump.  However, the action list is still incorrect
      and causes the following error if the user wants to look at the
      datapath flows:
      
        # ovs-dpctl add-dp system@ovs-system
        # ovs-dpctl add-flow "<flow match>" "clone(ct(commit),0)"
        # ovs-dpctl dump-flows
        <flow match>, packets:0, bytes:0, used:never,
          actions:clone(bad length 4, expected -1 for: action0(01 00 00 00),
                        ct(commit),0)
      
      With the fix:
      
        # ovs-dpctl dump-flows
        <flow match>, packets:0, bytes:0, used:never,
          actions:clone(ct(commit),0)
      
      Additionally fixed an incorrect attribute name in the comment.
      
      Fixes: b2335040 ("openvswitch: kernel datapath clone action")
      Signed-off-by: default avatarIlya Maximets <i.maximets@ovn.org>
      Acked-by: default avatarAaron Conole <aconole@redhat.com>
      Link: https://lore.kernel.org/r/20220404104150.2865736-1-i.maximets@ovn.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3f2a3050
    • Horatiu Vultur's avatar
      net: micrel: Fix KS8851 Kconfig · 1d7e4fd7
      Horatiu Vultur authored
      KS8851 selects MICREL_PHY, which depends on PTP_1588_CLOCK_OPTIONAL, so
      make KS8851 also depend on PTP_1588_CLOCK_OPTIONAL.
      
      Fixes kconfig warning and build errors:
      
      WARNING: unmet direct dependencies detected for MICREL_PHY
        Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && PTP_1588_CLOCK_OPTIONAL [=m]
          Selected by [y]:
            - KS8851 [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_MICREL [=y] && SPI [=y]
      
      ld.lld: error: undefined symbol: ptp_clock_register referenced by micrel.c
      net/phy/micrel.o:(lan8814_probe) in archive drivers/built-in.a
      ld.lld: error: undefined symbol: ptp_clock_index referenced by micrel.c
      net/phy/micrel.o:(lan8814_ts_info) in archive drivers/built-in.a
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Fixes: ece19502 ("net: phy: micrel: 1588 support for LAN8814 phy")
      Signed-off-by: default avatarHoratiu Vultur <horatiu.vultur@microchip.com>
      Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Link: https://lore.kernel.org/r/20220405065936.4105272-1-horatiu.vultur@microchip.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1d7e4fd7
  2. 05 Apr, 2022 11 commits
  3. 04 Apr, 2022 11 commits
  4. 03 Apr, 2022 2 commits
  5. 02 Apr, 2022 2 commits
  6. 01 Apr, 2022 1 commit
    • David S. Miller's avatar
      Merge branch 'nexthop-route-deletye-warning' · 37391cc8
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: ipv4: fix nexthop route delete warning
      
      The first patch fixes a warning that can be triggered by deleting a
      nexthop route and specifying a device (more info in its commit msg).
      And the second patch adds a selftest for that case.
      
      Chose this way to fix it because we should match when deleting without
      nh spec and should fail when deleting a nexthop route with old-style nh
      spec because nexthop objects are managed separately, e.g.:
      $ ip r show 1.2.3.4/32
      1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0
      
      $ ip r del 1.2.3.4/32
      $ ip r del 1.2.3.4/32 nhid 12
      <both should work>
      
      $ ip r del 1.2.3.4/32 dev dummy0
      <should fail with ESRCH>
      
      v2: addded more to patch 01's commit message
          adjusted the test comment in patch 02
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37391cc8