1. 25 Jul, 2023 2 commits
  2. 24 Jul, 2023 14 commits
  3. 23 Jul, 2023 9 commits
    • Patrick Rohr's avatar
      net: add sysctl accept_ra_min_rtr_lft · 1671bcfd
      Patrick Rohr authored
      This change adds a new sysctl accept_ra_min_rtr_lft to specify the
      minimum acceptable router lifetime in an RA. If the received RA router
      lifetime is less than the configured value (and not 0), the RA is
      ignored.
      This is useful for mobile devices, whose battery life can be impacted
      by networks that configure RAs with a short lifetime. On such networks,
      the device should never gain IPv6 provisioning and should attempt to
      drop RAs via hardware offload, if available.
      Signed-off-by: default avatarPatrick Rohr <prohr@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Lorenzo Colitti <lorenzo@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1671bcfd
    • justinstitt@google.com's avatar
      net: dsa: remove deprecated strncpy · 5c9f7b04
      justinstitt@google.com authored
      `strncpy` is deprecated for use on NUL-terminated destination strings [1].
      
      Even call sites utilizing length-bounded destination buffers should
      switch over to using `strtomem` or `strtomem_pad`. In this case,
      however, the compiler is unable to determine the size of the `data`
      buffer which renders `strtomem` unusable. Due to this, `strscpy`
      should be used.
      
      It should be noted that most call sites already zero-initialize the
      destination buffer. However, I've opted to use `strscpy_pad` to maintain
      the same exact behavior that `strncpy` produced (zero-padded tail up to
      `len`).
      
      Also see [3].
      
      [1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
      [2]: elixir.bootlin.com/linux/v6.3/source/net/ethtool/ioctl.c#L1944
      [3]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html
      
      Link: https://github.com/KSPP/linux/issues/90Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJustin Stitt <justinstitt@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c9f7b04
    • David S. Miller's avatar
      Merge branch 'process-connector-bug-fixes-and-enhancements' · 2e60314c
      David S. Miller authored
      Anjali Kulkarni says:
      
      ====================
      Process connector bug fixes & enhancements
      
      Oracle DB is trying to solve a performance overhead problem it has been
      facing for the past 10 years and using this patch series, we can fix this
      issue.
      
      Oracle DB runs on a large scale with 100000s of short lived processes,
      starting up and exiting quickly. A process monitoring DB daemon which
      tracks and cleans up after processes that have died without a proper exit
      needs notifications only when a process died with a non-zero exit code
      (which should be rare).
      
      Due to the pmon architecture, which is distributed, each process is
      independent and has minimal interaction with pmon. Hence fd based
      solutions to track a process's spawning and exit cannot be used. Pmon
      needs to detect the abnormal death of a process so it can cleanup after.
      Currently it resorts to checking /proc every few seconds. Other methods
      we tried like using system call to reduce the above overhead were not
      accepted upstream.
      
      With this change, we add event based filtering to proc connector module
      so that DB can only listen to the events it is interested in. A new
      event type PROC_EVENT_NONZERO_EXIT is added, which is only sent by kernel
      to a listening application when any process exiting has a non-zero exit
      status.
      
      This change will give Oracle DB substantial performance savings - it takes
      50ms to scan about 8K PIDs in /proc, about 500ms for 100K PIDs. DB does
      this check every 3 secs, so over an hour we save 10secs for 100K PIDs.
      
      With this, a client can register to listen for only exit or fork or a mix or
      all of the events. This greatly enhances performance - currently, we
      need to listen to all events, and there are 9 different types of events.
      For eg. handling 3 types of events - 8K-forks + 8K-exits + 8K-execs takes
      200ms, whereas handling 2 types - 8K-forks + 8K-exits takes about 150ms,
      and handling just one type - 8K exits takes about 70ms.
      
      Measuring the time using pidfds for monitoring 8K process exits took 4
      times longer - 200ms, as compared to 70ms using only exit notifications
      of proc connector. Hence, we cannot use pidfd for our use case.
      
      This kind of a new event could also be useful to other applications like
      Google's lmkd daemon, which needs a killed process's exit notification.
      
      This patch series is organized as follows -
      
      Patch 1 : Needed for patch 3 to work.
      Patch 2 : Needed for patch 3 to work.
      Patch 3 : Fixes some bugs in proc connector, details in the patch.
      Patch 4 : Adds event based filtering for performance enhancements.
      Patch 5 : Allow non-root users access to proc connector events.
      Patch 6 : Selftest code for proc connector.
      
      v9->v10 changes:
      - Rebased to net-next, re-compiled and re-tested.
      
      v8->v9 changes:
      - Added sha1 ("title") of reversed patch as suggested by Eric Dumazet.
      
      v7->v8 changes:
      - Fixed an issue pointed by Liam Howlett in v7.
      
      v6->v7 changes:
      - Incorporated Liam Howlett's comments on v6
      - Incorporated Kalesh Anakkur Purayil's comments
      
      v5->v6 changes:
      - Incorporated Liam Howlett's comments
      - Removed FILTER define from proc_filter.c and added a "-f" run-time
        option to run new filter code.
      - Made proc_filter.c a selftest in tools/testing/selftests/connector
      
      v4->v5 changes:
      - Change the cover letter
      - Fix a small issue in proc_filter.c
      
      v3->v4 changes:
      - Fix comments by Jakub Kicinski to incorporate root access changes
        within bind call of connector
      
      v2->v3 changes:
      - Fix comments by Jakub Kicinski to separate netlink (patch 2) (after
        layering) from connector fixes (patch 3).
      - Minor fixes suggested by Jakub.
      - Add new multicast group level permissions check at netlink layer.
        Split this into netlink & connector layers (patches 6 & 7)
      
      v1->v2 changes:
      - Fix comments by Jakub Kicinski to keep layering within netlink and
        update kdocs.
      - Move non-root users access patch last in series so remaining patches
        can go in first.
      
      v->v1 changes:
      - Changed commit log in patch 4 as suggested by Christian Brauner
      - Changed patch 4 to make more fine grained access to non-root users
      - Fixed warning in cn_proc.c,
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      - Fixed some existing warnings in cn_proc.c
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e60314c
    • Anjali Kulkarni's avatar
      connector/cn_proc: Selftest for proc connector · 73a29531
      Anjali Kulkarni authored
      Run as ./proc_filter -f to run new filter code. Run without "-f" to run
      usual proc connector code without the new filtering code.
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73a29531
    • Anjali Kulkarni's avatar
      connector/cn_proc: Allow non-root users access · bfdfdc2f
      Anjali Kulkarni authored
      There were a couple of reasons for not allowing non-root users access
      initially  - one is there was some point no proper receive buffer
      management in place for netlink multicast. But that should be long
      fixed. See link below for more context.
      
      Second is that some of the messages may contain data that is root only. But
      this should be handled with a finer granularity, which is being done at the
      protocol layer.  The only problematic protocols are nf_queue and the
      firewall netlink. Hence, this restriction for non-root access was relaxed
      for NETLINK_ROUTE initially:
      https://lore.kernel.org/all/20020612013101.A22399@wotan.suse.de/
      
      This restriction has also been removed for following protocols:
      NETLINK_KOBJECT_UEVENT, NETLINK_AUDIT, NETLINK_SOCK_DIAG,
      NETLINK_GENERIC, NETLINK_SELINUX.
      
      Since process connector messages are not sensitive (process fork, exit
      notifications etc.), and anyone can read /proc data, we can allow non-root
      access here. However, since process event notification is not the only
      consumer of NETLINK_CONNECTOR, we can make this change even more
      fine grained than the protocol level, by checking for multicast group
      within the protocol.
      
      Allow non-root access for NETLINK_CONNECTOR via NL_CFG_F_NONROOT_RECV
      but add new bind function cn_bind(), which allows non-root access only
      for CN_IDX_PROC multicast group.
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bfdfdc2f
    • Anjali Kulkarni's avatar
      connector/cn_proc: Performance improvements · 743acf35
      Anjali Kulkarni authored
      This patch adds the capability to filter messages sent by the proc
      connector on the event type supplied in the message from the client
      to the connector. The client can register to listen for an event type
      given in struct proc_input.
      
      This event based filteting will greatly enhance performance - handling
      8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms
      & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently
      9 different types of events, and we need to listen to all of them. Also,
      measuring the time using pidfds for monitoring 8K process exits took
      much longer - 200ms, as compared to 70ms using only exit notifications of
      proc connector.
      
      We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is
      only sent by kernel to a listening application when any process exiting,
      has a non-zero exit status. This will help the clients like Oracle DB,
      where a monitoring process wants notfications for non-zero process exits
      so it can cleanup after them.
      
      This kind of a new event could also be useful to other applications like
      Google's lmkd daemon, which needs a killed process's exit notification.
      
      The patch takes care that existing clients using old mechanism of not
      sending the event type work without any changes.
      
      cn_filter function checks to see if the event type being notified via
      proc connector matches the event type requested by client, before
      sending(matches) or dropping(does not match) a packet.
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      743acf35
    • Anjali Kulkarni's avatar
      connector/cn_proc: Add filtering to fix some bugs · 2aa1f7a1
      Anjali Kulkarni authored
      The current proc connector code has the foll. bugs - if there are more
      than one listeners for the proc connector messages, and one of them
      deregisters for listening using PROC_CN_MCAST_IGNORE, they will still get
      all proc connector messages, as long as there is another listener.
      
      Another issue is if one client calls PROC_CN_MCAST_LISTEN, and another one
      calls PROC_CN_MCAST_IGNORE, then both will end up not getting any messages.
      
      This patch adds filtering and drops packet if client has sent
      PROC_CN_MCAST_IGNORE. This data is stored in the client socket's
      sk_user_data. In addition, we only increment or decrement
      proc_event_num_listeners once per client. This fixes the above issues.
      
      cn_release is the release function added for NETLINK_CONNECTOR. It uses
      the newly added netlink_release function added to netlink_sock. It will
      free sk_user_data.
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2aa1f7a1
    • Anjali Kulkarni's avatar
      netlink: Add new netlink_release function · a4c9a56e
      Anjali Kulkarni authored
      A new function netlink_release is added in netlink_sock to store the
      protocol's release function. This is called when the socket is deleted.
      This can be supplied by the protocol via the release function in
      netlink_kernel_cfg. This is being added for the NETLINK_CONNECTOR
      protocol, so it can free it's data when socket is deleted.
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4c9a56e
    • Anjali Kulkarni's avatar
      netlink: Reverse the patch which removed filtering · a3377386
      Anjali Kulkarni authored
      To use filtering at the connector & cn_proc layers, we need to enable
      filtering in the netlink layer. This reverses the patch which removed
      netlink filtering - commit ID for that patch:
      549017aa (netlink: remove netlink_broadcast_filtered).
      Signed-off-by: default avatarAnjali Kulkarni <anjali.k.kulkarni@oracle.com>
      Reviewed-by: default avatarLiam R. Howlett <Liam.Howlett@oracle.com>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3377386
  4. 22 Jul, 2023 7 commits
  5. 21 Jul, 2023 8 commits
    • David S. Miller's avatar
      Merge branch 'octeontx2-pf-round-robin-sched' · 2da6a804
      David S. Miller authored
      Hariprasad Kelam says:
      
      ====================
      octeontx2-pf: support Round Robin scheduling
      
      octeontx2 and CN10K silicons support Round Robin scheduling. When multiple
      traffic flows reach transmit level with the same priority, with Round Robin
      scheduling traffic flow with the highest quantum value is picked. With this
      support, the user can add multiple classes with the same priority and
      different quantum in htb offload.
      
      This series of patches adds support for the same.
      
      Patch1: implement transmit schedular allocation algorithm as preparation
              for support round robin scheduling.
      
      Patch2: Allow quantum parameter in HTB offload mode.
      
      Patch3: extends octeontx2 htb offload support for Round Robin scheduling
      
      Patch4: extend QOS documentation for Round Robin scheduling
      
      Hariprasad Kelam (1):
        docs: octeontx2: extend documentation for Round Robin scheduling
      
      Naveen Mamindlapalli (3):
        octeontx2-pf: implement transmit schedular allocation algorithm
        sch_htb: Allow HTB quantum parameter in offload mode
        octeontx2-pf: htb offload support for Round Robin scheduling
      ---
      v4 * update classid values in documentation.
      
      v3 * 1. update QOS documentation for round robin scheduling
           2. added out of bound checks for quantum parameter
      
      v2 * change data type of otx2_index_used to reduce size of structure
           otx2_qos_cfg
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2da6a804
    • Hariprasad Kelam's avatar
      docs: octeontx2: extend documentation for Round Robin scheduling · 6f71051f
      Hariprasad Kelam authored
      Add example tc-htb commands for Round robin scheduling
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f71051f
    • Naveen Mamindlapalli's avatar
      octeontx2-pf: htb offload support for Round Robin scheduling · 47a9656f
      Naveen Mamindlapalli authored
      When multiple traffic flows reach Transmit level with the same
      priority, with Round robin scheduling traffic flow with the highest
      quantum value is picked. With this support, the user can add multiple
      classes with the same priority and different quantum. This patch
      does necessary changes to support the same.
      Signed-off-by: default avatarNaveen Mamindlapalli <naveenm@marvell.com>
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47a9656f
    • Naveen Mamindlapalli's avatar
      sch_htb: Allow HTB quantum parameter in offload mode · 9fe63d5f
      Naveen Mamindlapalli authored
      The current implementation of HTB offload returns the EINVAL error for
      quantum parameter. This patch removes the error returning checks for
      'quantum' parameter and populates its value to tc_htb_qopt_offload
      structure such that driver can use the same.
      
      Add quantum parameter check in mlx5 driver, as mlx5 devices are not capable
      of supporting the quantum parameter when htb offload is used. Report error
      if quantum parameter is set to a non-default value.
      Signed-off-by: default avatarNaveen Mamindlapalli <naveenm@marvell.com>
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9fe63d5f
    • Naveen Mamindlapalli's avatar
      octeontx2-pf: implement transmit schedular allocation algorithm · f78dca69
      Naveen Mamindlapalli authored
      unlike strict priority, where number of classes are limited to max
      8, there is no restriction on the number of dwrr child nodes unless
      the count increases the max number of child nodes supported.
      
      Hardware expects strict priority transmit schedular indexes mapped
      to their priority. This patch adds defines transmit schedular allocation
      algorithm such that the above requirement is honored.
      Signed-off-by: default avatarNaveen Mamindlapalli <naveenm@marvell.com>
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f78dca69
    • David S. Miller's avatar
      Merge branch 'mlxsw-enslavement' · c6514f36
      David S. Miller authored
      Petr Machata says:
      
      ====================
      mlxsw: Permit enslavement to netdevices with uppers
      
      The mlxsw driver currently makes the assumption that the user applies
      configuration in a bottom-up manner. Thus netdevices need to be added to
      the bridge before IP addresses are configured on that bridge or SVI added
      on top of it. Enslaving a netdevice to another netdevice that already has
      uppers is in fact forbidden by mlxsw for this reason. Despite this safety,
      it is rather easy to get into situations where the offloaded configuration
      is just plain wrong.
      
      As an example, take a front panel port, configure an IP address: it gets a
      RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the
      port from the bridge again, but the RIF never comes back. There is a number
      of similar situations, where changing the configuration there and back
      utterly breaks the offload.
      
      Similarly, detaching a front panel port from a configured topology means
      unoffloading of this whole topology -- VLAN uppers, next hops, etc.
      Attaching the port back is then not permitted at all. If it were, it would
      not result in a working configuration, because much of mlxsw is written to
      react to changes in immediate configuration. There is nothing that would go
      visit netdevices in the attached-to topology and offload existing routes
      and VLAN memberships, for example.
      
      In this patchset, introduce a number of replays to be invoked so that this
      sort of post-hoc offload is supported. Then remove the vetoes that
      disallowed enslavement of front panel ports to other netdevices with
      uppers.
      
      The patchset progresses as follows:
      
      - In patch #1, fix an issue in the bridge driver. To my knowledge, the
        issue could not have resulted in a buggy behavior previously, and thus is
        packaged with this patchset instead of being sent separately to net.
      
      - In patch #2, add a new helper to the switchdev code.
      
      - In patch #3, drop mlxsw selftests that will not be relevant after this
        patchset anymore.
      
      - Patches #4, #5, #6, #7 and #8 prepare the codebase for smoother
        introduction of the rest of the code.
      
      - Patches #9, #10, #11, #12, #13 and #14 replay various aspects of upper
        configuration when a front panel port is introduced into a topology.
        Individual patches take care of bridge and LAG RIF memberships, switchdev
        replay, nexthop and neighbors replay, and MACVLAN offload.
      
      - Patches #15 and #16 introduce RIFs for newly-relevant netdevices when a
        front panel port is enslaved (in which case all uppers are newly
        relevant), or, respectively, deslaved (in which case the newly-relevant
        netdevice is the one being deslaved).
      
      - Up until this point, the introduced scaffolding was not really used,
        because mlxsw still forbids enslavement of mlxsw netdevices to uppers
        with uppers. In patch #17, this condition is finally relaxed.
      
      A sizable selftest suite is available to test all this new code. That will
      be sent in a separate patchset.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6514f36
    • Petr Machata's avatar
      mlxsw: spectrum: Permit enslavement to netdevices with uppers · 2c5ffe8d
      Petr Machata authored
      Enslaving of front panel ports (and their uppers) to netdevices that
      already have uppers is currently forbidden. In the previous patches, a
      number of replays have been added. Those ensure that various bits of state,
      such as next hops or switchdev objects, are offloaded when they become
      relevant due to a mlxsw lower being introduced into the topology.
      
      However the act of actually, for example, enslaving a front-panel port to
      a bridge with uppers, has been vetoed so far. In this patch, remove the
      vetoes and permit the operation.
      
      mlxsw currently validates creation of "interesting" uppers. Thus creating
      VLAN netdevices on top of 802.1ad bridges is forbidden if the bridge has an
      mlxsw lower, but permitted in general. This validation code never gets run
      when a port is introduced as a lower of an existing netdevice structure.
      
      Thus when enslaving an mlxsw netdevice to netdevices with uppers, invoke
      the PRECHANGEUPPER event handler for each netdevice above the one that the
      front panel port is being enslaved to. This way the tower of netdevices
      above the attachment point is validated.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c5ffe8d
    • Petr Machata's avatar
      mlxsw: spectrum_router: Replay IP NETDEV_UP on device deslavement · 4560cf40
      Petr Machata authored
      When a netdevice is removed from a bridge or a LAG, and it has an IP
      address, it should join the router and gain a RIF. Do that by replaying
      address addition event on the netdevice.
      
      When handling deslavement of LAG or its upper from a bridge device, the
      replay should be done after all the lowers of the LAG have left the bridge.
      Thus these scenarios are handled by passing replay_deslavement of false,
      and by invoking, after the lowers have been processed, a new helper,
      mlxsw_sp_netdevice_post_lag_event(), which does the per-LAG / -upper
      handling, and in particular invokes the replay.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4560cf40