1. 08 3月, 2023 1 次提交
  2. 20 2月, 2023 1 次提交
  3. 16 2月, 2023 1 次提交
    • I
      devlink: Fix netdev notifier chain corruption · b20b8aec
      Ido Schimmel 提交于
      Cited commit changed devlink to register its netdev notifier block on
      the global netdev notifier chain instead of on the per network namespace
      one.
      
      However, when changing the network namespace of the devlink instance,
      devlink still tries to unregister its notifier block from the chain of
      the old namespace and register it on the chain of the new namespace.
      This results in corruption of the notifier chains, as the same notifier
      block is registered on two different chains: The global one and the per
      network namespace one. In turn, this causes other problems such as the
      inability to dismantle namespaces due to netdev reference count issues.
      
      Fix by preventing devlink from moving its notifier block between
      namespaces.
      
      Reproducer:
      
       # echo "10 1" > /sys/bus/netdevsim/new_device
       # ip netns add test123
       # devlink dev reload netdevsim/netdevsim10 netns test123
       # ip netns del test123
       [   71.935619] unregister_netdevice: waiting for lo to become free. Usage count = 2
       [   71.938348] leaked reference.
      
      Fixes: 565b4824 ("devlink: change port event netdev notifier from per-net to global")
      Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: NJiri Pirko <jiri@nvidia.com>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: NJakub Kicinski <kuba@kernel.org>
      Link: https://lore.kernel.org/r/20230215073139.1360108-1-idosch@nvidia.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      b20b8aec
  4. 10 2月, 2023 1 次提交
  5. 08 2月, 2023 1 次提交
  6. 03 2月, 2023 1 次提交
  7. 02 2月, 2023 1 次提交
  8. 27 1月, 2023 2 次提交
  9. 24 1月, 2023 1 次提交
    • S
      bpf: XDP metadata RX kfuncs · 3d76a4d3
      Stanislav Fomichev 提交于
      Define a new kfunc set (xdp_metadata_kfunc_ids) which implements all possible
      XDP metatada kfuncs. Not all devices have to implement them. If kfunc is not
      supported by the target device, the default implementation is called instead.
      The verifier, at load time, replaces a call to the generic kfunc with a call
      to the per-device one. Per-device kfunc pointers are stored in separate
      struct xdp_metadata_ops.
      
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Martin KaFai Lau <martin.lau@linux.dev>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: Willem de Bruijn <willemb@google.com>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Anatoly Burakov <anatoly.burakov@intel.com>
      Cc: Alexander Lobakin <alexandr.lobakin@intel.com>
      Cc: Magnus Karlsson <magnus.karlsson@gmail.com>
      Cc: Maryam Tahhan <mtahhan@redhat.com>
      Cc: xdp-hints@xdp-project.net
      Cc: netdev@vger.kernel.org
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Link: https://lore.kernel.org/r/20230119221536.3349901-8-sdf@google.comSigned-off-by: NMartin KaFai Lau <martin.lau@kernel.org>
      3d76a4d3
  10. 13 12月, 2022 1 次提交
    • X
      net: add IFF_NO_ADDRCONF and use it in bonding to prevent ipv6 addrconf · 8a321cf7
      Xin Long 提交于
      Currently, in bonding it reused the IFF_SLAVE flag and checked it
      in ipv6 addrconf to prevent ipv6 addrconf.
      
      However, it is not a proper flag to use for no ipv6 addrconf, for
      bonding it has to move IFF_SLAVE flag setting ahead of dev_open()
      in bond_enslave(). Also, IFF_MASTER/SLAVE are historical flags
      used in bonding and eql, as Jiri mentioned, the new devices like
      Team, Failover do not use this flag.
      
      So as Jiri suggested, this patch adds IFF_NO_ADDRCONF in priv_flags
      of the device to indicate no ipv6 addconf, and uses it in bonding
      and moves IFF_SLAVE flag setting back to its original place.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8a321cf7
  11. 05 12月, 2022 2 次提交
  12. 04 12月, 2022 1 次提交
  13. 16 11月, 2022 2 次提交
  14. 10 11月, 2022 1 次提交
  15. 09 11月, 2022 1 次提交
    • A
      net/core: Allow live renaming when an interface is up · bd039b5e
      Andy Ren 提交于
      Allow a network interface to be renamed when the interface
      is up.
      
      As described in the netconsole documentation [1], when netconsole is
      used as a built-in, it will bring up the specified interface as soon as
      possible. As a result, user space will not be able to rename the
      interface since the kernel disallows renaming of interfaces that are
      administratively up unless the 'IFF_LIVE_RENAME_OK' private flag was set
      by the kernel.
      
      The original solution [2] to this problem was to add a new parameter to
      the netconsole configuration parameters that allows renaming of
      the interface used by netconsole while it is administratively up.
      However, during the discussion that followed, it became apparent that we
      have no reason to keep the current restriction and instead we should
      allow user space to rename interfaces regardless of their administrative
      state:
      
      1. The restriction was put in place over 20 years ago when renaming was
      only possible via IOCTL and before rtnetlink started notifying user
      space about such changes like it does today.
      
      2. The 'IFF_LIVE_RENAME_OK' flag was added over 3 years ago in version
      5.2 and no regressions were reported.
      
      3. In-kernel listeners to 'NETDEV_CHANGENAME' do not seem to care about
      the administrative state of interface.
      
      Therefore, allow user space to rename running interfaces by removing the
      restriction and the associated 'IFF_LIVE_RENAME_OK' flag. Help in
      possible triage by emitting a message to the kernel log that an
      interface was renamed while UP.
      
      [1] https://www.kernel.org/doc/Documentation/networking/netconsole.rst
      [2] https://lore.kernel.org/netdev/20221102002420.2613004-1-andy.ren@getcruise.com/Signed-off-by: NAndy Ren <andy.ren@getcruise.com>
      Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: NDavid Ahern <dsahern@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd039b5e
  16. 04 11月, 2022 2 次提交
  17. 01 11月, 2022 1 次提交
  18. 31 10月, 2022 1 次提交
  19. 15 10月, 2022 1 次提交
  20. 02 10月, 2022 1 次提交
  21. 30 9月, 2022 2 次提交
  22. 29 9月, 2022 1 次提交
  23. 20 9月, 2022 1 次提交
    • V
      net: introduce iterators over synced hw addresses · db01868b
      Vladimir Oltean 提交于
      Some network drivers use __dev_mc_sync()/__dev_uc_sync() and therefore
      program the hardware only with addresses with a non-zero sync_cnt.
      
      Some of the above drivers also need to save/restore the address
      filtering lists when certain events happen, and they need to walk
      through the struct net_device :: uc and struct net_device :: mc lists.
      But these lists contain unsynced addresses too.
      
      To keep the appearance of an elementary form of data encapsulation,
      provide iterators through these lists that only look at entries with a
      non-zero sync_cnt, instead of filtering entries out from device drivers.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      db01868b
  24. 02 9月, 2022 2 次提交
  25. 26 8月, 2022 1 次提交
  26. 24 8月, 2022 2 次提交
  27. 22 8月, 2022 1 次提交
  28. 25 6月, 2022 1 次提交
  29. 10 6月, 2022 2 次提交
  30. 23 5月, 2022 1 次提交
  31. 16 5月, 2022 2 次提交
    • F
      net: fix dev_fill_forward_path with pppoe + bridge · cf2df74e
      Felix Fietkau 提交于
      When calling dev_fill_forward_path on a pppoe device, the provided destination
      address is invalid. In order for the bridge fdb lookup to succeed, the pppoe
      code needs to update ctx->daddr to the correct value.
      Fix this by storing the address inside struct net_device_path_ctx
      
      Fixes: f6efc675 ("net: ppp: resolve forwarding path for bridge pppoe devices")
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      cf2df74e
    • E
      net: fix possible race in skb_attempt_defer_free() · 97e719a8
      Eric Dumazet 提交于
      A cpu can observe sd->defer_count reaching 128,
      and call smp_call_function_single_async()
      
      Problem is that the remote CPU can clear sd->defer_count
      before the IPI is run/acknowledged.
      
      Other cpus can queue more packets and also decide
      to call smp_call_function_single_async() while the pending
      IPI was not yet delivered.
      
      This is a common issue with smp_call_function_single_async().
      Callers must ensure correct synchronization and serialization.
      
      I triggered this issue while experimenting smaller threshold.
      Performing the call to smp_call_function_single_async()
      under sd->defer_lock protection did not solve the problem.
      
      Commit 5a18ceca ("smp: Allow smp_call_function_single_async()
      to insert locked csd") replaced an informative WARN_ON_ONCE()
      with a return of -EBUSY, which is often ignored.
      Test of CSD_FLAG_LOCK presence is racy anyway.
      
      Fixes: 68822bdf ("net: generalize skb freeing deferral to per-cpu lists")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97e719a8