1. 14 Feb, 2024 34 commits
    • Eric Dumazet's avatar
      net: convert dev->reg_state to u8 · 4d42b37d
      Eric Dumazet authored
      Prepares things so that dev->reg_state reads can be lockless,
      by adding WRITE_ONCE() on write side.
      
      READ_ONCE()/WRITE_ONCE() do not support bitfields.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4d42b37d
    • Eric Dumazet's avatar
      dev: annotate accesses to dev->link · a6473fe9
      Eric Dumazet authored
      Following patch will read dev->link locklessly,
      annotate the write from do_setlink().
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6473fe9
    • Eric Dumazet's avatar
      ip_tunnel: annotate data-races around t->parms.link · f694eee9
      Eric Dumazet authored
      t->parms.link is read locklessly, annotate these reads
      and opposite writes accordingly.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f694eee9
    • Eric Dumazet's avatar
      net: annotate data-races around dev->name_assign_type · 1c07dbb0
      Eric Dumazet authored
      name_assign_type_show() runs locklessly, we should annotate
      accesses to dev->name_assign_type.
      
      Alternative would be to grab devnet_rename_sem semaphore
      from name_assign_type_show(), but this would not bring
      more accuracy.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c07dbb0
    • David S. Miller's avatar
      Merge branch 'per-epoll-context-busy-poll' · b7f9ef72
      David S. Miller authored
      Joe Damato says:
      
      ====================
      Per epoll context busy poll support
      
      Greetings:
      
      Welcome to v8.
      
      TL;DR This builds on commit bf3b9f63 ("epoll: Add busy poll support to
      epoll with socket fds.") by allowing user applications to enable
      epoll-based busy polling, set a busy poll packet budget, and enable or
      disable prefer busy poll on a per epoll context basis.
      
      This makes epoll-based busy polling much more usable for user
      applications than the current system-wide sysctl and hardcoded budget.
      
      To allow for this, two ioctls have been added for epoll contexts for
      getting and setting a new struct, struct epoll_params.
      
      ioctl was chosen vs a new syscall after reviewing a suggestion by Willem
      de Bruijn [1]. I am open to using a new syscall instead of an ioctl, but it
      seemed that:
        - Busy poll affects all existing epoll_wait and epoll_pwait variants in
          the same way, so new verions of many syscalls might be needed. It
          seems much simpler for users to use the correct
          epoll_wait/epoll_pwait for their app and add a call to ioctl to enable
          or disable busy poll as needed. This also probably means less work to
          get an existing epoll app using busy poll.
      
        - previously added epoll_pwait2 helped to bring epoll closer to
          existing syscalls (like pselect and ppoll) and this busy poll change
          reflected as a new syscall would not have the same effect.
      
      Note: patch 1/4 as of v4 uses an or (||) instead of an xor. I thought about
      it some more and I realized that if the user enables both the per-epoll
      context setting and the system wide sysctl, then busy poll should be
      enabled and not disabled. Using xor doesn't seem to make much sense after
      thinking through this a bit.
      
      Longer explanation:
      
      Presently epoll has support for a very useful form of busy poll based on
      the incoming NAPI ID (see also: SO_INCOMING_NAPI_ID [2]).
      
      This form of busy poll allows epoll_wait to drive NAPI packet processing
      which allows for a few interesting user application designs which can
      reduce latency and also potentially improve L2/L3 cache hit rates by
      deferring NAPI until userland has finished its work.
      
      The documentation available on this is, IMHO, a bit confusing so please
      allow me to explain how one might use this:
      
      1. Ensure each application thread has its own epoll instance mapping
      1-to-1 with NIC RX queues. An n-tuple filter would likely be used to
      direct connections with specific dest ports to these queues.
      
      2. Optionally: Setup IRQ coalescing for the NIC RX queues where busy
      polling will occur. This can help avoid the userland app from being
      pre-empted by a hard IRQ while userland is running. Note this means that
      userland must take care to call epoll_wait and not take too long in
      userland since it now drives NAPI via epoll_wait.
      
      3. Optionally: Consider using napi_defer_hard_irqs and gro_flush_timeout to
      further restrict IRQ generation from the NIC. These settings are
      system-wide so their impact must be carefully weighed against the running
      applications.
      
      4. Ensure that all incoming connections added to an epoll instance
      have the same NAPI ID. This can be done with a BPF filter when
      SO_REUSEPORT is used or getsockopt + SO_INCOMING_NAPI_ID when a single
      accept thread is used which dispatches incoming connections to threads.
      
      5. Lastly, busy poll must be enabled via a sysctl
      (/proc/sys/net/core/busy_poll).
      
      Please see Eric Dumazet's paper about busy polling [3] and a recent
      academic paper about measured performance improvements of busy polling [4]
      (albeit with a modification that is not currently present in the kernel)
      for additional context.
      
      The unfortunate part about step 5 above is that this enables busy poll
      system-wide which affects all user applications on the system,
      including epoll-based network applications which were not intended to
      be used this way or applications where increased CPU usage for lower
      latency network processing is unnecessary or not desirable.
      
      If the user wants to run one low latency epoll-based server application
      with epoll-based busy poll, but would like to run the rest of the
      applications on the system (which may also use epoll) without busy poll,
      this system-wide sysctl presents a significant problem.
      
      This change preserves the system-wide sysctl, but adds a mechanism (via
      ioctl) to enable or disable busy poll for epoll contexts as needed by
      individual applications, making epoll-based busy poll more usable.
      
      Note that this change includes an or (as of v4) instead of an xor. If the
      user has enabled both the system-wide sysctl and also the per epoll-context
      busy poll settings, then epoll should probably busy poll (vs being
      disabled).
      
      Thanks,
      Joe
      
      v7 -> v8:
         - Reviewed-by tag from Eric Dumazet applied to commit message of patch
           1/4.
      
         - patch 4/4:
           - EPIOCSPARAMS and EPIOCGPARAMS updated to use WRITE_ONCE and
             READ_ONCE, as requested by Eric Dumazet
           - Wrapped a long line (via netdev/checkpatch)
      
      v6 -> v7:
         - Acked-by tags from Stanislav Fomichev applied to commit messages of
           all patches.
         - Reviewed-by tags from Jakub Kicinski, Eric Dumazet applied to commit
           messages of patches 2 and 3. Jiri Slaby's Reviewed-by applied to patch
           4.
      
         - patch 1/4:
           - busy_poll_usecs reduced from u64 to u32.
           - Unnecessary parens removed (via netdev/checkpatch)
           - Wrapped long line (via netdev/checkpatch)
           - Remove inline from busy_loop_ep_timeout as objdump suggests the
             function is already inlined
           - Moved struct eventpoll assignment to declaration
           - busy_loop_ep_timeout is moved within CONFIG_NET_RX_BUSY_POLL and the
             ifdefs internally have been removed as per Eric Dumazet's review
           - Removed ep_busy_loop_on from the !defined CONFIG_NET_RX_BUSY_POLL
             section as it is only called when CONFIG_NET_RX_BUSY_POLL is
             defined
      
         - patch 3/4:
           - Fix whitespace alignment issue (via netdev/checkpatch)
      
         - patch 4/4:
           - epoll_params.busy_poll_usecs has been reduced to u32
           - epoll_params.busy_poll_usecs is now checked to ensure it is <=
             S32_MAX
           - __pad has been reduced to a single u8
           - memchr_inv has been dropped and replaced with a simple check for the
             single __pad byte
           - Removed space after cast (via netdev/checkpatch)
           - Wrap long line (via netdev/checkpatch)
           - Move struct eventpoll *ep assignment to declaration as per Jiri
             Slaby's review
           - Remove unnecessary !! as per Jiri Slaby's review
           - Reorganized variables to be reverse christmas tree order
      
      v5 -> v6:
        - patch 1/3 no functional change, but commit message corrected to explain
          that an or (||) is being used instead of xor.
      
        - patch 3/4 is a new patch which adds support for per epoll context
          prefer busy poll setting.
      
        - patch 4/4 updated to allow getting/setting per epoll context prefer
          busy poll setting; this setting is limited to either 0 or 1.
      
      v4 -> v5:
        - patch 3/3 updated to use memchr_inv to ensure that __pad is zero for
          the EPIOCSPARAMS ioctl. Recommended by Greg K-H [5], Dave Chinner [6],
          and Jiri Slaby [7].
      
      v3 -> v4:
        - patch 1/3 was updated to include an important functional change:
          ep_busy_loop_on was updated to use or (||) instead of xor (^). After
          thinking about it a bit more, I thought xor didn't make much sense.
          Enabling both the per-epoll context and the system-wide sysctl should
          probably enable busy poll, not disable it. So, or (||) makes more
          sense, I think.
      
        - patch 3/3 was updated:
          - to change the epoll_params fields to be __u64, __u16, and __u8 and
            to pad the struct to a multiple of 64bits. Suggested by Greg K-H [8]
            and Arnd Bergmann [9].
          - remove an unused pr_fmt, left over from the previous revision.
          - ioctl now returns -EINVAL when epoll_params.busy_poll_usecs >
            U32_MAX.
      
      v2 -> v3:
        - cover letter updated to mention why ioctl seems (to me) like a better
          choice vs a new syscall.
      
        - patch 3/4 was modified in 3 ways:
          - when an unknown ioctl is received, -ENOIOCTLCMD is returned instead
            of -EINVAL as the ioctl documentation requires.
          - epoll_params.busy_poll_budget can only be set to a value larger than
            NAPI_POLL_WEIGHT if code is run by privileged (CAP_NET_ADMIN) users.
            Otherwise, -EPERM is returned.
          - busy poll specific ioctl code moved out to its own function. On
            kernels without busy poll support, -EOPNOTSUPP is returned. This also
            makes the kernel build robot happier without littering the code with
            more #ifdefs.
      
        - dropped patch 4/4 after Eric Dumazet's review of it when it was sent
          independently to the list [10].
      
      v1 -> v2:
        - cover letter updated to make a mention of napi_defer_hard_irqs and
          gro_flush_timeout as an added step 3 and to cite both Eric Dumazet's
          busy polling paper and a paper from University of Waterloo for
          additional context. Specifically calling out the xor in patch 1/4
          incase it is missed by reviewers.
      
        - Patch 2/4 has its commit message updated, but no functional changes.
          Commit message now describes that allowing for a settable budget helps
          to improve throughput and is more consistent with other busy poll
          mechanisms that allow a settable budget via SO_BUSY_POLL_BUDGET.
      
        - Patch 3/4 was modified to check if the epoll_params.busy_poll_budget
          exceeds NAPI_POLL_WEIGHT. The larger value is allowed, but an error is
          printed. This was done for consistency with netif_napi_add_weight,
          which does the same.
      
        - Patch 3/4 the struct epoll_params was updated to fix the type of the
          data field; it was uint8_t and was changed to u8.
      
        - Patch 4/4 added to check if SO_BUSY_POLL_BUDGET exceeds
          NAPI_POLL_WEIGHT. The larger value is allowed, but an error is
          printed. This was done for consistency with netif_napi_add_weight,
          which does the same.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7f9ef72
    • Joe Damato's avatar
      eventpoll: Add epoll ioctl for epoll_params · 18e2bf0e
      Joe Damato authored
      Add an ioctl for getting and setting epoll_params. User programs can use
      this ioctl to get and set the busy poll usec time, packet budget, and
      prefer busy poll params for a specific epoll context.
      
      Parameters are limited:
        - busy_poll_usecs is limited to <= s32_max
        - busy_poll_budget is limited to <= NAPI_POLL_WEIGHT by unprivileged
          users (!capable(CAP_NET_ADMIN))
        - prefer_busy_poll must be 0 or 1
        - __pad must be 0
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Reviewed-by: default avatarJiri Slaby <jirislaby@kernel.org>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18e2bf0e
    • Joe Damato's avatar
      eventpoll: Add per-epoll prefer busy poll option · de57a251
      Joe Damato authored
      When using epoll-based busy poll, the prefer_busy_poll option is hardcoded
      to false. Users may want to enable prefer_busy_poll to be used in
      conjunction with gro_flush_timeout and defer_hard_irqs_count to keep device
      IRQs masked.
      
      Other busy poll methods allow enabling or disabling prefer busy poll via
      SO_PREFER_BUSY_POLL, but epoll-based busy polling uses a hardcoded value.
      
      Fix this edge case by adding support for a per-epoll context
      prefer_busy_poll option. The default is false, as it was hardcoded before
      this change.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de57a251
    • Joe Damato's avatar
      eventpoll: Add per-epoll busy poll packet budget · c6aa2a77
      Joe Damato authored
      When using epoll-based busy poll, the packet budget is hardcoded to
      BUSY_POLL_BUDGET (8). Users may desire larger busy poll budgets, which
      can potentially increase throughput when busy polling under high network
      load.
      
      Other busy poll methods allow setting the busy poll budget via
      SO_BUSY_POLL_BUDGET, but epoll-based busy polling uses a hardcoded
      value.
      
      Fix this edge case by adding support for a per-epoll context busy poll
      packet budget. If not specified, the default value (BUSY_POLL_BUDGET) is
      used.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6aa2a77
    • Joe Damato's avatar
      eventpoll: support busy poll per epoll instance · 85455c79
      Joe Damato authored
      Allow busy polling on a per-epoll context basis. The per-epoll context
      usec timeout value is preferred, but the pre-existing system wide sysctl
      value is still supported if it specified.
      
      busy_poll_usecs is a u32, but in a follow up patch the ioctl provided to
      the user only allows setting a value from 0 to S32_MAX.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Acked-by: default avatarStanislav Fomichev <sdf@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      85455c79
    • Kamal Heib's avatar
      net: ena: Remove redundant assignment · 723615a1
      Kamal Heib authored
      There is no point in initializing an ndo to NULL, therefore the
      assignment is redundant and can be removed.
      Signed-off-by: default avatarKamal Heib <kheib@redhat.com>
      Reviewed-by: default avatarBrett Creeley <brett.creeley@amd.com>
      Acked-by: default avatarArthur Kiyanovski <akiyano@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      723615a1
    • Hariprasad Kelam's avatar
      Octeontx2-af: Fetch MAC channel info from firmware · 99781449
      Hariprasad Kelam authored
      Packet ingress and egress MAC/serdes channel numbers are configurable
      on CN10K series of silicons. These channel numbers inturn used while
      installing MCAM rules to match ingress/egress port. Fetch these channel
      numbers from firmware at driver init time.
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarSunil Kovvuri Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99781449
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · b53e8464
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      Intel Wired LAN Driver Updates 2024-02-12 (ice)
      
      This series contains updates to ice driver only.
      
      Grzegorz adds support for E825-C devices.
      
      Wojciech reworks devlink reload to fulfill expected conditions (remove
      and readd).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b53e8464
    • David S. Miller's avatar
      Merge tag 'linux-can-next-for-6.9-20240213' of... · e1a00373
      David S. Miller authored
      Merge tag 'linux-can-next-for-6.9-20240213' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
      
      Marc Kleine-Budde says:
      
      ====================
      linux-can-next-for-6.9-20240213
      
      this is a pull request of 23 patches for net-next/master.
      
      The first patch is by Nicolas Maier and targets the CAN Broadcast
      Manager (bcm), it adds message flags to distinguish between own local
      and remote traffic.
      
      Oliver Hartkopp contributes a patch for the CAN ISOTP protocol that
      adds dynamic flow control parameters.
      
      Stefan Mätje's patch series add support for the esd PCIe/402 CAN
      interface family.
      
      Markus Schneider-Pargmann contributes 14 patches for the m_can to
      optimize for the SPI attached tcan4x5x controller.
      
      A patch by Vincent Mailhol replaces Wolfgang Grandegger by Vincent
      Mailhol as the CAN drivers Co-Maintainer.
      
      Jimmy Assarsson's patch add support for the Kvaser M.2 PCIe 4xCAN
      adapter.
      
      A patch by Daniil Dulov removed a redundant NULL check in the softing
      driver.
      
      Oliver Hartkopp contributes a patch to add CANXL virtual CAN network
      identifier support.
      
      A patch by myself removes Naga Sureshkumar Relli as the maintainer of
      the xilinx_can driver, as their email bounces.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1a00373
    • Jakub Kicinski's avatar
      Merge branch 'add-multi-buff-support-for-xdp-running-in-generic-mode' · f77581bf
      Jakub Kicinski authored
      Lorenzo Bianconi says:
      
      ====================
      add multi-buff support for xdp running in generic mode
      
      Introduce multi-buffer support for xdp running in generic mode not always
      linearizing the skb in netif_receive_generic_xdp routine.
      Introduce generic percpu page_pools allocator.
      ====================
      
      Link: https://lore.kernel.org/r/cover.1707729884.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f77581bf
    • Lorenzo Bianconi's avatar
    • Lorenzo Bianconi's avatar
      xdp: add multi-buff support for xdp running in generic mode · e6d5dbdd
      Lorenzo Bianconi authored
      Similar to native xdp, do not always linearize the skb in
      netif_receive_generic_xdp routine but create a non-linear xdp_buff to be
      processed by the eBPF program. This allow to add multi-buffer support
      for xdp running in generic mode.
      Acked-by: default avatarJesper Dangaard Brouer <hawk@kernel.org>
      Reviewed-by: default avatarToke Hoiland-Jorgensen <toke@redhat.com>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://lore.kernel.org/r/1044d6412b1c3e95b40d34993fd5f37cd2f319fd.1707729884.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e6d5dbdd
    • Lorenzo Bianconi's avatar
      xdp: rely on skb pointer reference in do_xdp_generic and netif_receive_generic_xdp · 4d2bb0bf
      Lorenzo Bianconi authored
      Rely on skb pointer reference instead of the skb pointer in do_xdp_generic
      and netif_receive_generic_xdp routine signatures.
      This is a preliminary patch to add multi-buff support for xdp running in
      generic mode where we will need to reallocate the skb to avoid
      linearization and we will need to make it visible to do_xdp_generic()
      caller.
      Acked-by: default avatarJesper Dangaard Brouer <hawk@kernel.org>
      Reviewed-by: default avatarToke Hoiland-Jorgensen <toke@redhat.com>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://lore.kernel.org/r/c09415b1f48c8620ef4d76deed35050a7bddf7c2.1707729884.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4d2bb0bf
    • Lorenzo Bianconi's avatar
      net: add generic percpu page_pool allocator · 2b0cfa6e
      Lorenzo Bianconi authored
      Introduce generic percpu page_pools allocator.
      Moreover add page_pool_create_percpu() and cpuid filed in page_pool struct
      in order to recycle the page in the page_pool "hot" cache if
      napi_pp_put_page() is running on the same cpu.
      This is a preliminary patch to add xdp multi-buff support for xdp running
      in generic mode.
      Acked-by: default avatarJesper Dangaard Brouer <hawk@kernel.org>
      Reviewed-by: default avatarToke Hoiland-Jorgensen <toke@redhat.com>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Link: https://lore.kernel.org/r/80bc4285228b6f4220cd03de1999d86e46e3fcbd.1707729884.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2b0cfa6e
    • Luiz Angelo Daros de Luca's avatar
      net: dsa: realtek: fix digital interface select macro for EXT0 · 32e4a544
      Luiz Angelo Daros de Luca authored
      While no supported devices currently utilize EXT0, the register reserves
      the bits for an EXT0. EXT0 is utilized by devices from the generation
      prior to rtl8365mb, such as those supported by the driver library
      rtl8367b.
      Signed-off-by: default avatarLuiz Angelo Daros de Luca <luizluca@gmail.com>
      Reviewed-by: default avatarAlvin Šipraga <alsi@bang-olufsen.dk>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://lore.kernel.org/r/20240212-realtek-fix_ext0-v1-1-f3d2536d191a@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      32e4a544
    • Jakub Kicinski's avatar
      Merge branch 'r8169-extend-eee-tx-idle-timer-support' · 239ce99c
      Jakub Kicinski authored
      Heiner Kallweit says:
      
      ====================
      r8169: extend EEE tx idle timer support
      
      This series extends EEE tx idle timer support, and exposes the timer
      value to userspace.
      ====================
      
      Link: https://lore.kernel.org/r/89a5fef5-a4b7-4d5d-9c35-764248be5a19@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      239ce99c
    • Heiner Kallweit's avatar
      r8169: add support for returning tx_lpi_timer in ethtool get_eee · 9c501397
      Heiner Kallweit authored
      Add support for returning the tx_lpi_timer value to userspace.
      This is supported by few chip versions only: RTL8168h/RTL8125/RTL8126
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/4eee9c34-c5d6-4c96-9b05-455896dea59a@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9c501397
    • Heiner Kallweit's avatar
      57d2d2c8
    • Heiner Kallweit's avatar
      r8169: add generic rtl_set_eee_txidle_timer function · 2ce30993
      Heiner Kallweit authored
      Add a generic setter for the EEE tx idle timer and use it with all
      RTL8125/RTL8126 chip versions, in line with the vendor driver.
      This prepares for adding EEE tx idle timer support for additional
      chip versions.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/39beed72-0dc4-4c45-8899-b72c43ab62a7@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2ce30993
    • Heiner Kallweit's avatar
      r8169: add LED support for RTL8125/RTL8126 · be51ed10
      Heiner Kallweit authored
      This adds LED support for RTL8125/RTL8126.
      
      Note: Due to missing datasheets changing the 5Gbps link mode isn't
      supported for RTL8126.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/f982602c-9de3-4ca6-85a3-2c1d118dcb15@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      be51ed10
    • Krzysztof Kozlowski's avatar
    • Csókás Bence's avatar
      net: fec: Refactor: Replace FEC_ENET_FCE with FEC_RCR_FLOWCTL · f7859a03
      Csókás Bence authored
      FEC_ENET_FCE is the Flow Control Enable bit (bit 5) of the RCR.
      This is now defined as FEC_RCR_FLOWCTL.
      Signed-off-by: default avatarCsókás Bence <csokas.bence@prolan.hu>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20240212153717.10023-2-csokas.bence@prolan.huSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f7859a03
    • Csókás Bence's avatar
      net: fec: Refactor: #define magic constants · ff049886
      Csókás Bence authored
      Add defines for bits of ECR, RCR control registers, TX watermark etc.
      Signed-off-by: default avatarCsókás Bence <csokas.bence@prolan.hu>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20240212153717.10023-1-csokas.bence@prolan.huSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ff049886
    • Jakub Kicinski's avatar
      Merge branch 'net-adopt-netdev_lockdep_set_classes' · 65d53afd
      Jakub Kicinski authored
      Eric Dumazet says:
      
      ====================
      net: adopt netdev_lockdep_set_classes()
      
      Instead of waiting for syzbot to discover lockdep false positives,
      make sure we use netdev_lockdep_set_classes() a bit more.
      ====================
      
      Link: https://lore.kernel.org/r/20240212140700.2795436-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      65d53afd
    • Eric Dumazet's avatar
      net: add netdev_lockdep_set_classes() to virtual drivers · 0bef5120
      Eric Dumazet authored
      Based on a syzbot report, it appears many virtual
      drivers do not yet use netdev_lockdep_set_classes(),
      triggerring lockdep false positives.
      
      WARNING: possible recursive locking detected
      6.8.0-rc4-next-20240212-syzkaller #0 Not tainted
      
      syz-executor.0/19016 is trying to acquire lock:
       ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
       ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
       ffff8880162cb298 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
      
      but task is already holding lock:
       ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
       ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
       ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
        lock(_xmit_ETHER#2);
        lock(_xmit_ETHER#2);
      
       *** DEADLOCK ***
      
       May be due to missing lock nesting notation
      
      9 locks held by syz-executor.0/19016:
        #0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline]
        #0: ffffffff8f385208 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x82c/0x1040 net/core/rtnetlink.c:6603
        #1: ffffc90000a08c00 ((&in_dev->mr_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0xc0/0x600 kernel/time/timer.c:1697
        #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]
        #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]
        #2: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228
        #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline]
        #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline]
        #3: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284
        #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline]
        #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline]
        #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline]
        #4: ffff8880416e3258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325
        #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline]
        #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: __netif_tx_lock include/linux/netdevice.h:4452 [inline]
        #5: ffff8880223db4d8 (_xmit_ETHER#2){+.-.}-{2:2}, at: sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
        #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]
        #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]
        #6: ffffffff8e131520 (rcu_read_lock){....}-{1:2}, at: ip_finish_output2+0x45f/0x1360 net/ipv4/ip_output.c:228
        #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: local_bh_disable include/linux/bottom_half.h:20 [inline]
        #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: rcu_read_lock_bh include/linux/rcupdate.h:802 [inline]
        #7: ffffffff8e131580 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x2c4/0x3b10 net/core/dev.c:4284
        #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: spin_trylock include/linux/spinlock.h:361 [inline]
        #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: qdisc_run_begin include/net/sch_generic.h:195 [inline]
        #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_xmit_skb net/core/dev.c:3771 [inline]
        #8: ffff888014d9d258 (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+...}-{2:2}, at: __dev_queue_xmit+0x1262/0x3b10 net/core/dev.c:4325
      
      stack backtrace:
      CPU: 1 PID: 19016 Comm: syz-executor.0 Not tainted 6.8.0-rc4-next-20240212-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
      Call Trace:
       <IRQ>
        __dump_stack lib/dump_stack.c:88 [inline]
        dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
        check_deadlock kernel/locking/lockdep.c:3062 [inline]
        validate_chain+0x15c1/0x58e0 kernel/locking/lockdep.c:3856
        __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
        lock_acquire+0x1e4/0x530 kernel/locking/lockdep.c:5754
        __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
        _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154
        spin_lock include/linux/spinlock.h:351 [inline]
        __netif_tx_lock include/linux/netdevice.h:4452 [inline]
        sch_direct_xmit+0x1c4/0x5f0 net/sched/sch_generic.c:340
        __dev_xmit_skb net/core/dev.c:3784 [inline]
        __dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325
        neigh_output include/net/neighbour.h:542 [inline]
        ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235
        iptunnel_xmit+0x540/0x9b0 net/ipv4/ip_tunnel_core.c:82
        ip_tunnel_xmit+0x20ee/0x2960 net/ipv4/ip_tunnel.c:831
        erspan_xmit+0x9de/0x1460 net/ipv4/ip_gre.c:720
        __netdev_start_xmit include/linux/netdevice.h:4989 [inline]
        netdev_start_xmit include/linux/netdevice.h:5003 [inline]
        xmit_one net/core/dev.c:3555 [inline]
        dev_hard_start_xmit+0x242/0x770 net/core/dev.c:3571
        sch_direct_xmit+0x2b6/0x5f0 net/sched/sch_generic.c:342
        __dev_xmit_skb net/core/dev.c:3784 [inline]
        __dev_queue_xmit+0x1912/0x3b10 net/core/dev.c:4325
        neigh_output include/net/neighbour.h:542 [inline]
        ip_finish_output2+0xe66/0x1360 net/ipv4/ip_output.c:235
        igmpv3_send_cr net/ipv4/igmp.c:723 [inline]
        igmp_ifc_timer_expire+0xb71/0xd90 net/ipv4/igmp.c:813
        call_timer_fn+0x17e/0x600 kernel/time/timer.c:1700
        expire_timers kernel/time/timer.c:1751 [inline]
        __run_timers+0x621/0x830 kernel/time/timer.c:2038
        run_timer_softirq+0x67/0xf0 kernel/time/timer.c:2051
        __do_softirq+0x2bc/0x943 kernel/softirq.c:554
        invoke_softirq kernel/softirq.c:428 [inline]
        __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
        irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
        instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1076 [inline]
        sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1076
       </IRQ>
       <TASK>
        asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
       RIP: 0010:resched_offsets_ok kernel/sched/core.c:10127 [inline]
       RIP: 0010:__might_resched+0x16f/0x780 kernel/sched/core.c:10142
      Code: 00 4c 89 e8 48 c1 e8 03 48 ba 00 00 00 00 00 fc ff df 48 89 44 24 38 0f b6 04 10 84 c0 0f 85 87 04 00 00 41 8b 45 00 c1 e0 08 <01> d8 44 39 e0 0f 85 d6 00 00 00 44 89 64 24 1c 48 8d bc 24 a0 00
      RSP: 0018:ffffc9000ee069e0 EFLAGS: 00000246
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8880296a9e00
      RDX: dffffc0000000000 RSI: ffff8880296a9e00 RDI: ffffffff8bfe8fa0
      RBP: ffffc9000ee06b00 R08: ffffffff82326877 R09: 1ffff11002b5ad1b
      R10: dffffc0000000000 R11: ffffed1002b5ad1c R12: 0000000000000000
      R13: ffff8880296aa23c R14: 000000000000062a R15: 1ffff92001dc0d44
        down_write+0x19/0x50 kernel/locking/rwsem.c:1578
        kernfs_activate fs/kernfs/dir.c:1403 [inline]
        kernfs_add_one+0x4af/0x8b0 fs/kernfs/dir.c:819
        __kernfs_create_file+0x22e/0x2e0 fs/kernfs/file.c:1056
        sysfs_add_file_mode_ns+0x24a/0x310 fs/sysfs/file.c:307
        create_files fs/sysfs/group.c:64 [inline]
        internal_create_group+0x4f4/0xf20 fs/sysfs/group.c:152
        internal_create_groups fs/sysfs/group.c:192 [inline]
        sysfs_create_groups+0x56/0x120 fs/sysfs/group.c:218
        create_dir lib/kobject.c:78 [inline]
        kobject_add_internal+0x472/0x8d0 lib/kobject.c:240
        kobject_add_varg lib/kobject.c:374 [inline]
        kobject_init_and_add+0x124/0x190 lib/kobject.c:457
        netdev_queue_add_kobject net/core/net-sysfs.c:1706 [inline]
        netdev_queue_update_kobjects+0x1f3/0x480 net/core/net-sysfs.c:1758
        register_queue_kobjects net/core/net-sysfs.c:1819 [inline]
        netdev_register_kobject+0x265/0x310 net/core/net-sysfs.c:2059
        register_netdevice+0x1191/0x19c0 net/core/dev.c:10298
        bond_newlink+0x3b/0x90 drivers/net/bonding/bond_netlink.c:576
        rtnl_newlink_create net/core/rtnetlink.c:3506 [inline]
        __rtnl_newlink net/core/rtnetlink.c:3726 [inline]
        rtnl_newlink+0x158f/0x20a0 net/core/rtnetlink.c:3739
        rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6606
        netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
        netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
        netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
        netlink_sendmsg+0xa3c/0xd70 net/netlink/af_netlink.c:1908
        sock_sendmsg_nosec net/socket.c:730 [inline]
        __sock_sendmsg+0x221/0x270 net/socket.c:745
        __sys_sendto+0x3a4/0x4f0 net/socket.c:2191
        __do_sys_sendto net/socket.c:2203 [inline]
        __se_sys_sendto net/socket.c:2199 [inline]
        __x64_sys_sendto+0xde/0x100 net/socket.c:2199
       do_syscall_64+0xfb/0x240
       entry_SYSCALL_64_after_hwframe+0x6d/0x75
      RIP: 0033:0x7fc3fa87fa9c
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240212140700.2795436-4-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0bef5120
    • Eric Dumazet's avatar
      net: bridge: use netdev_lockdep_set_classes() · c74e1039
      Eric Dumazet authored
      br_set_lockdep_class() is missing many details.
      Use generic netdev_lockdep_set_classes() to not worry anymore.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240212140700.2795436-3-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c74e1039
    • Eric Dumazet's avatar
      vlan: use netdev_lockdep_set_classes() · 9a3c93af
      Eric Dumazet authored
      vlan uses vlan_dev_set_lockdep_class() which lacks qdisc_tx_busylock
      initialization.
      
      Use generic netdev_lockdep_set_classes() to not worry anymore.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20240212140700.2795436-2-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9a3c93af
    • Jakub Kicinski's avatar
      Merge branch 'net-use-net-dev_by_index-in-two-places' · 88c9d07b
      Jakub Kicinski authored
      Eric Dumazet says:
      
      ====================
      net: use net->dev_by_index in two places
      
      Bring "ip link" ordering to /proc/net/dev one (by ifindexes).
      
      Do the same for /proc/net/vlan/config
      
      v2: https://lore.kernel.org/all/20240209142441.6c56435b@kernel.org/
      ====================
      
      Link: https://lore.kernel.org/r/20240211214404.1882191-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      88c9d07b
    • Eric Dumazet's avatar
      rtnetlink: use xarray iterator to implement rtnl_dump_ifinfo() · 3e41af90
      Eric Dumazet authored
      Adopt net->dev_by_index as I did in commit 0e0939c0
      ("net-procfs: use xarray iterator to implement /proc/net/dev")
      
      This makes sure an existing device is always visible in the dump,
      regardless of concurrent insertions/deletions.
      
      v2: added suggestions from Jakub Kicinski and Ido Schimmel,
          thanks for the help !
      
      Link: https://lore.kernel.org/all/20240209142441.6c56435b@kernel.org/
      Link: https://lore.kernel.org/all/ZckR-XOsULLI9EHc@shredder/Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://lore.kernel.org/r/20240211214404.1882191-3-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3e41af90
    • Eric Dumazet's avatar
      vlan: use xarray iterator to implement /proc/net/vlan/config · f383ced2
      Eric Dumazet authored
      Adopt net->dev_by_index as I did in commit 0e0939c0
      ("net-procfs: use xarray iterator to implement /proc/net/dev")
      
      Not only this removes quadratic behavior, it also makes sure
      an existing vlan device is always visible in the dump,
      regardless of concurrent net->dev_base_head changes.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://lore.kernel.org/r/20240211214404.1882191-2-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f383ced2
  2. 13 Feb, 2024 6 commits