1. 25 3月, 2021 1 次提交
    • P
      net: resolve forwarding path from virtual netdevice and HW destination address · ddb94eaf
      Pablo Neira Ayuso 提交于
      This patch adds dev_fill_forward_path() which resolves the path to reach
      the real netdevice from the IP forwarding side. This function takes as
      input the netdevice and the destination hardware address and it walks
      down the devices calling .ndo_fill_forward_path() for each device until
      the real device is found.
      
      For instance, assuming the following topology:
      
                     IP forwarding
                    /             \
                 br0              eth0
                 / \
             eth1  eth2
              .
              .
              .
             ethX
       ab:cd:ef:ab:cd:ef
      
      where eth1 and eth2 are bridge ports and eth0 provides WAN connectivity.
      ethX is the interface in another box which is connected to the eth1
      bridge port.
      
      For packets going through IP forwarding to br0 whose destination MAC
      address is ab:cd:ef:ab:cd:ef, dev_fill_forward_path() provides the
      following path:
      
      	br0 -> eth1
      
      .ndo_fill_forward_path for br0 looks up at the FDB for the bridge port
      from the destination MAC address to get the bridge port eth1.
      
      This information allows to create a fast path that bypasses the classic
      bridge and IP forwarding paths, so packets go directly from the bridge
      port eth1 to eth0 (wan interface) and vice versa.
      
                   fast path
            .------------------------.
           /                          \
          |           IP forwarding   |
          |          /             \  \/
          |       br0               eth0
          .       / \
           -> eth1  eth2
              .
              .
              .
             ethX
       ab:cd:ef:ab:cd:ef
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddb94eaf
  2. 24 3月, 2021 1 次提交
    • D
      net: make unregister netdev warning timeout configurable · 5aa3afe1
      Dmitry Vyukov 提交于
      netdev_wait_allrefs() issues a warning if refcount does not drop to 0
      after 10 seconds. While 10 second wait generally should not happen
      under normal workload in normal environment, it seems to fire falsely
      very often during fuzzing and/or in qemu emulation (~10x slower).
      At least it's not possible to understand if it's really a false
      positive or not. Automated testing generally bumps all timeouts
      to very high values to avoid flake failures.
      Add net.core.netdev_unregister_timeout_secs sysctl to make
      the timeout configurable for automated testing systems.
      Lowering the timeout may also be useful for e.g. manual bisection.
      The default value matches the current behavior.
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=211877
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5aa3afe1
  3. 23 3月, 2021 2 次提交
  4. 20 3月, 2021 1 次提交
    • E
      net: add CONFIG_PCPU_DEV_REFCNT · 919067cc
      Eric Dumazet 提交于
      I was working on a syzbot issue, claiming one device could not be
      dismantled because its refcount was -1
      
      unregister_netdevice: waiting for sit0 to become free. Usage count = -1
      
      It would be nice if syzbot could trigger a warning at the time
      this reference count became negative.
      
      This patch adds CONFIG_PCPU_DEV_REFCNT options which defaults
      to per cpu variables (as before this patch) on SMP builds.
      
      v2: free_dev label in alloc_netdev_mqs() is moved to avoid
          a compiler warning (-Wunused-label), as reported
          by kernel test robot <lkp@intel.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      919067cc
  5. 19 3月, 2021 8 次提交
  6. 16 3月, 2021 1 次提交
  7. 15 3月, 2021 3 次提交
  8. 11 3月, 2021 1 次提交
  9. 14 2月, 2021 2 次提交
  10. 13 2月, 2021 1 次提交
  11. 12 2月, 2021 1 次提交
    • C
      net: fix dev_ifsioc_locked() race condition · 3b23a32a
      Cong Wang 提交于
      dev_ifsioc_locked() is called with only RCU read lock, so when
      there is a parallel writer changing the mac address, it could
      get a partially updated mac address, as shown below:
      
      Thread 1			Thread 2
      // eth_commit_mac_addr_change()
      memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
      				// dev_ifsioc_locked()
      				memcpy(ifr->ifr_hwaddr.sa_data,
      					dev->dev_addr,...);
      
      Close this race condition by guarding them with a RW semaphore,
      like netdev_get_name(). We can not use seqlock here as it does not
      allow blocking. The writers already take RTNL anyway, so this does
      not affect the slow path. To avoid bothering existing
      dev_set_mac_address() callers in drivers, introduce a new wrapper
      just for user-facing callers on ioctl and rtnetlink paths.
      
      Note, bonding also changes slave mac addresses but that requires
      a separate patch due to the complexity of bonding code.
      
      Fixes: 3710becf ("net: RCU locking for simple ioctl()")
      Reported-by: N"Gong, Sishuai" <sishuai@purdue.edu>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Signed-off-by: NCong Wang <cong.wang@bytedance.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b23a32a
  12. 10 2月, 2021 3 次提交
  13. 06 2月, 2021 1 次提交
  14. 05 2月, 2021 1 次提交
    • L
      net/core: move gro function declarations to separate header · 04f00ab2
      Leon Romanovsky 提交于
      Fir the following compilation warnings:
       1031 | INDIRECT_CALLABLE_SCOPE void udp_v6_early_demux(struct sk_buff *skb)
      
      net/ipv6/ip6_offload.c:182:41: warning: no previous prototype for ‘ipv6_gro_receive’ [-Wmissing-prototypes]
        182 | INDIRECT_CALLABLE_SCOPE struct sk_buff *ipv6_gro_receive(struct list_head *head,
            |                                         ^~~~~~~~~~~~~~~~
      net/ipv6/ip6_offload.c:320:29: warning: no previous prototype for ‘ipv6_gro_complete’ [-Wmissing-prototypes]
        320 | INDIRECT_CALLABLE_SCOPE int ipv6_gro_complete(struct sk_buff *skb, int nhoff)
            |                             ^~~~~~~~~~~~~~~~~
      net/ipv6/ip6_offload.c:182:41: warning: no previous prototype for ‘ipv6_gro_receive’ [-Wmissing-prototypes]
        182 | INDIRECT_CALLABLE_SCOPE struct sk_buff *ipv6_gro_receive(struct list_head *head,
            |                                         ^~~~~~~~~~~~~~~~
      net/ipv6/ip6_offload.c:320:29: warning: no previous prototype for ‘ipv6_gro_complete’ [-Wmissing-prototypes]
        320 | INDIRECT_CALLABLE_SCOPE int ipv6_gro_complete(struct sk_buff *skb, int nhoff)
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      04f00ab2
  15. 30 1月, 2021 1 次提交
    • X
      net: support ip generic csum processing in skb_csum_hwoffload_help · 62fafcd6
      Xin Long 提交于
      NETIF_F_IP|IPV6_CSUM feature flag indicates UDP and TCP csum offload
      while NETIF_F_HW_CSUM feature flag indicates ip generic csum offload
      for HW, which includes not only for TCP/UDP csum, but also for other
      protocols' csum like GRE's.
      
      However, in skb_csum_hwoffload_help() it only checks features against
      NETIF_F_CSUM_MASK(NETIF_F_HW|IP|IPV6_CSUM). So if it's a non TCP/UDP
      packet and the features doesn't support NETIF_F_HW_CSUM, but supports
      NETIF_F_IP|IPV6_CSUM only, it would still return 0 and leave the HW
      to do csum.
      
      This patch is to support ip generic csum processing by checking
      NETIF_F_HW_CSUM for all protocols, and check (NETIF_F_IP_CSUM |
      NETIF_F_IPV6_CSUM) only for TCP and UDP.
      
      Note that we're using skb->csum_offset to check if it's a TCP/UDP
      proctol, this might be fragile. However, as Alex said, for now we
      only have a few L4 protocols that are requesting Tx csum offload,
      we'd better fix this until a new protocol comes with a same csum
      offset.
      
      v1->v2:
        - not extend skb->csum_not_inet, but use skb->csum_offset to tell
          if it's an UDP/TCP csum packet.
      v2->v3:
        - add a note in the changelog, as Willem suggested.
      Suggested-by: NAlexander Duyck <alexander.duyck@gmail.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      62fafcd6
  16. 23 1月, 2021 1 次提交
  17. 21 1月, 2021 5 次提交
  18. 20 1月, 2021 2 次提交
  19. 19 1月, 2021 1 次提交
  20. 15 1月, 2021 1 次提交
  21. 14 1月, 2021 1 次提交
  22. 10 1月, 2021 1 次提交