Skip to content
  1. Aug 25, 2022
    • Jacob Keller's avatar
      ixgbe: stop resetting SYSTIME in ixgbe_ptp_start_cyclecounter · 25d7a5f5
      Jacob Keller authored
      The ixgbe_ptp_start_cyclecounter is intended to be called whenever the
      cyclecounter parameters need to be changed.
      
      Since commit a9763f3c
      
       ("ixgbe: Update PTP to support X550EM_x
      devices"), this function has cleared the SYSTIME registers and reset the
      TSAUXC DISABLE_SYSTIME bit.
      
      While these need to be cleared during ixgbe_ptp_reset, it is wrong to clear
      them during ixgbe_ptp_start_cyclecounter. This function may be called
      during both reset and link status change. When link changes, the SYSTIME
      counter is still operating normally, but the cyclecounter should be updated
      to account for the possibly changed parameters.
      
      Clearing SYSTIME when link changes causes the timecounter to jump because
      the cycle counter now reads zero.
      
      Extract the SYSTIME initialization out to a new function and call this
      during ixgbe_ptp_reset. This prevents the timecounter adjustment and avoids
      an unnecessary reset of the current time.
      
      This also restores the original SYSTIME clearing that occurred during
      ixgbe_ptp_reset before the commit above.
      
      Reported-by: default avatarSteve Payne <spayne@aurora.tech>
      Reported-by: default avatarIlya Evenbach <ievenbach@aurora.tech>
      Fixes: a9763f3c
      
       ("ixgbe: Update PTP to support X550EM_x devices")
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      25d7a5f5
  2. Aug 24, 2022
  3. Aug 23, 2022
    • Vladimir Oltean's avatar
      net: dsa: don't dereference NULL extack in dsa_slave_changeupper() · 855a28f9
      Vladimir Oltean authored
      When a driver returns -EOPNOTSUPP in dsa_port_bridge_join() but failed
      to provide a reason for it, DSA attempts to set the extack to say that
      software fallback will kick in.
      
      The problem is, when we use brctl and the legacy bridge ioctls, the
      extack will be NULL, and DSA dereferences it in the process of setting
      it.
      
      Sergei Antonov proves this using the following stack trace:
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      PC is at dsa_slave_changeupper+0x5c/0x158
      
       dsa_slave_changeupper from raw_notifier_call_chain+0x38/0x6c
       raw_notifier_call_chain from __netdev_upper_dev_link+0x198/0x3b4
       __netdev_upper_dev_link from netdev_master_upper_dev_link+0x50/0x78
       netdev_master_upper_dev_link from br_add_if+0x430/0x7f4
       br_add_if from br_ioctl_stub+0x170/0x530
       br_ioctl_stub from br_ioctl_call+0x54/0x7c
       br_ioctl_call from dev_ifsioc+0x4e0/0x6bc
       dev_ifsioc from dev_ioctl+0x2f8/0x758
       dev_ioctl from sock_ioctl+0x5f0/0x674
       sock_ioctl from sys_ioctl+0x518/0xe40
       sys_ioctl from ret_fast_syscall+0x0/0x1c
      
      Fix the problem by only overriding the extack if non-NULL.
      
      Fixes: 1c6e8088
      
       ("net: dsa: allow port_bridge_join() to override extack message")
      Link: https://lore.kernel.org/netdev/CABikg9wx7vB5eRDAYtvAm7fprJ09Ta27a4ZazC=NX5K4wn6pWA@mail.gmail.com/
      Reported-by: default avatarSergei Antonov <saproj@gmail.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarSergei Antonov <saproj@gmail.com>
      Link: https://lore.kernel.org/r/20220819173925.3581871-1-vladimir.oltean@nxp.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      855a28f9
    • Maciej Żenczykowski's avatar
      net: ipvtap - add __init/__exit annotations to module init/exit funcs · 4b2e3a17
      Maciej Żenczykowski authored
      Looks to have been left out in an oversight.
      
      Cc: Mahesh Bandewar <maheshb@google.com>
      Cc: Sainath Grandhi <sainath.grandhi@intel.com>
      Fixes: 235a9d89
      
       ('ipvtap: IP-VLAN based tap driver')
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      Link: https://lore.kernel.org/r/20220821130808.12143-1-zenczykowski@gmail.com
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      4b2e3a17
    • Jakub Kicinski's avatar
      Merge branch 'bonding-802-3ad-fix-no-transmission-of-lacpdus' · 5003e52c
      Jakub Kicinski authored
      
      
      Jonathan Toppins says:
      
      ====================
      bonding: 802.3ad: fix no transmission of LACPDUs
      
      Configuring a bond in a specific order can leave the bond in a state
      where it never transmits LACPDUs.
      
      The first patch adds some kselftest infrastructure and the reproducer
      that demonstrates the problem. The second patch fixes the issue. The
      new third patch makes ad_ticks_per_sec a static const and removes the
      passing of this variable via the stack.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1660919940.git.jtoppins@redhat.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5003e52c
    • Jonathan Toppins's avatar
      bonding: 3ad: make ad_ticks_per_sec a const · f2e44dff
      Jonathan Toppins authored
      
      
      The value is only ever set once in bond_3ad_initialize and only ever
      read otherwise. There seems to be no reason to set the variable via
      bond_3ad_initialize when setting the global variable will do. Change
      ad_ticks_per_sec to a const to enforce its read-only usage.
      
      Signed-off-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f2e44dff
    • Jonathan Toppins's avatar
      bonding: 802.3ad: fix no transmission of LACPDUs · d745b506
      Jonathan Toppins authored
      This is caused by the global variable ad_ticks_per_sec being zero as
      demonstrated by the reproducer script discussed below. This causes
      all timer values in __ad_timer_to_ticks to be zero, resulting
      in the periodic timer to never fire.
      
      To reproduce:
      Run the script in
      `tools/testing/selftests/drivers/net/bonding/bond-break-lacpdu-tx.sh` which
      puts bonding into a state where it never transmits LACPDUs.
      
      line 44: ip link add fbond type bond mode 4 miimon 200 \
                  xmit_hash_policy 1 ad_actor_sys_prio 65535 lacp_rate fast
      setting bond param: ad_actor_sys_prio
      given:
          params.ad_actor_system = 0
      call stack:
          bond_option_ad_actor_sys_prio()
          -> bond_3ad_update_ad_actor_settings()
             -> set ad.system.sys_priority = bond->params.ad_actor_sys_prio
             -> ad.system.sys_mac_addr = bond->dev->dev_addr; because
                  params.ad_actor_system == 0
      results:
           ad.system.sys_mac_addr = bond->dev->dev_addr
      
      line 48: ip link set fbond address 52:54:00:3B:7C:A6
      setting bond MAC addr
      call stack:
          bond->dev->dev_addr = new_mac
      
      line 52: ip link set fbond type bond ad_actor_sys_prio 65535
      setting bond param: ad_actor_sys_prio
      given:
          params.ad_actor_system = 0
      call stack:
          bond_option_ad_actor_sys_prio()
          -> bond_3ad_update_ad_actor_settings()
             -> set ad.system.sys_priority = bond->params.ad_actor_sys_prio
             -> ad.system.sys_mac_addr = bond->dev->dev_addr; because
                  params.ad_actor_system == 0
      results:
           ad.system.sys_mac_addr = bond->dev->dev_addr
      
      line 60: ip link set veth1-bond down master fbond
      given:
          params.ad_actor_system = 0
          params.mode = BOND_MODE_8023AD
          ad.system.sys_mac_addr == bond->dev->dev_addr
      call stack:
          bond_enslave
          -> bond_3ad_initialize(); because first slave
             -> if ad.system.sys_mac_addr != bond->dev->dev_addr
                return
      results:
           Nothing is run in bond_3ad_initialize() because dev_addr equals
           sys_mac_addr leaving the global ad_ticks_per_sec zero as it is
           never initialized anywhere else.
      
      The if check around the contents of bond_3ad_initialize() is no longer
      needed due to commit 5ee14e6d ("bonding: 3ad: apply ad_actor settings
      changes immediately") which sets ad.system.sys_mac_addr if any one of
      the bonding parameters whos set function calls
      bond_3ad_update_ad_actor_settings(). This is because if
      ad.system.sys_mac_addr is zero it will be set to the current bond mac
      address, this causes the if check to never be true.
      
      Fixes: 5ee14e6d
      
       ("bonding: 3ad: apply ad_actor settings changes immediately")
      Signed-off-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d745b506
    • Jonathan Toppins's avatar
      selftests: include bonding tests into the kselftest infra · c078290a
      Jonathan Toppins authored
      
      
      This creates a test collection in drivers/net/bonding for bonding
      specific kernel selftests.
      
      The first test is a reproducer that provisions a bond and given the
      specific order in how the ip-link(8) commands are issued the bond never
      transmits an LACPDU frame on any of its slaves.
      
      Signed-off-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c078290a
    • Sergei Antonov's avatar
      net: moxa: get rid of asymmetry in DMA mapping/unmapping · 0ee7828d
      Sergei Antonov authored
      Since priv->rx_mapping[i] is maped in moxart_mac_open(), we
      should unmap it from moxart_mac_stop(). Fixes 2 warnings.
      
      1. During error unwinding in moxart_mac_probe(): "goto init_fail;",
      then moxart_mac_free_memory() calls dma_unmap_single() with
      priv->rx_mapping[i] pointers zeroed.
      
      WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:963 check_unmap+0x704/0x980
      DMA-API: moxart-ethernet 92000000.mac: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=1600 bytes]
      CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0+ #60
      Hardware name: Generic DT based system
       unwind_backtrace from show_stack+0x10/0x14
       show_stack from dump_stack_lvl+0x34/0x44
       dump_stack_lvl from __warn+0xbc/0x1f0
       __warn from warn_slowpath_fmt+0x94/0xc8
       warn_slowpath_fmt from check_unmap+0x704/0x980
       check_unmap from debug_dma_unmap_page+0x8c/0x9c
       debug_dma_unmap_page from moxart_mac_free_memory+0x3c/0xa8
       moxart_mac_free_memory from moxart_mac_probe+0x190/0x218
       moxart_mac_probe from platform_probe+0x48/0x88
       platform_probe from really_probe+0xc0/0x2e4
      
      2. After commands:
       ip link set dev eth0 down
       ip link set dev eth0 up
      
      WARNING: CPU: 0 PID: 55 at kernel/dma/debug.c:570 add_dma_entry+0x204/0x2ec
      DMA-API: moxart-ethernet 92000000.mac: cacheline tracking EEXIST, overlapping mappings aren't supported
      CPU: 0 PID: 55 Comm: ip Not tainted 5.19.0+ #57
      Hardware name: Generic DT based system
       unwind_backtrace from show_stack+0x10/0x14
       show_stack from dump_stack_lvl+0x34/0x44
       dump_stack_lvl from __warn+0xbc/0x1f0
       __warn from warn_slowpath_fmt+0x94/0xc8
       warn_slowpath_fmt from add_dma_entry+0x204/0x2ec
       add_dma_entry from dma_map_page_attrs+0x110/0x328
       dma_map_page_attrs from moxart_mac_open+0x134/0x320
       moxart_mac_open from __dev_open+0x11c/0x1ec
       __dev_open from __dev_change_flags+0x194/0x22c
       __dev_change_flags from dev_change_flags+0x14/0x44
       dev_change_flags from devinet_ioctl+0x6d4/0x93c
       devinet_ioctl from inet_ioctl+0x1ac/0x25c
      
      v1 -> v2:
      Extraneous change removed.
      
      Fixes: 6c821bd9
      
       ("net: Add MOXA ART SoCs ethernet driver")
      Signed-off-by: default avatarSergei Antonov <saproj@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220819110519.1230877-1-saproj@gmail.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0ee7828d
    • Xiaolei Wang's avatar
      net: phy: Don't WARN for PHY_READY state in mdio_bus_phy_resume() · 6dbe852c
      Xiaolei Wang authored
      For some MAC drivers, they set the mac_managed_pm to true in its
      ->ndo_open() callback. So before the mac_managed_pm is set to true,
      we still want to leverage the mdio_bus_phy_suspend()/resume() for
      the phy device suspend and resume. In this case, the phy device is
      in PHY_READY, and we shouldn't warn about this. It also seems that
      the check of mac_managed_pm in WARN_ON is redundant since we already
      check this in the entry of mdio_bus_phy_resume(), so drop it.
      
      Fixes: 744d23c7
      
       ("net: phy: Warn about incorrect mdio_bus_phy_resume() state")
      Signed-off-by: default avatarXiaolei Wang <xiaolei.wang@windriver.com>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20220819082451.1992102-1-xiaolei.wang@windriver.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6dbe852c
    • Alex Elder's avatar
      net: ipa: don't assume SMEM is page-aligned · b8d43803
      Alex Elder authored
      In ipa_smem_init(), a Qualcomm SMEM region is allocated (if needed)
      and then its virtual address is fetched using qcom_smem_get().  The
      physical address associated with that region is also fetched.
      
      The physical address is adjusted so that it is page-aligned, and an
      attempt is made to update the size of the region to compensate for
      any non-zero adjustment.
      
      But that adjustment isn't done properly.  The physical address is
      aligned twice, and as a result the size is never actually adjusted.
      
      Fix this by *not* aligning the "addr" local variable, and instead
      making the "phys" local variable be the adjusted "addr" value.
      
      Fixes: a0036bb4
      
       ("net: ipa: define SMEM memory region for IPA")
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Link: https://lore.kernel.org/r/20220818134206.567618-1-elder@linaro.org
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b8d43803