1. 21 Apr, 2023 34 commits
    • David S. Miller's avatar
      Merge branch 'macsec-vlan' · 1cf3fe1c
      David S. Miller authored
      Emeel Hakim says:
      
      ====================
      Support MACsec VLAN
      
      This patch series introduces support for hardware (HW) offload MACsec
      devices with VLAN configuration. The patches address both scenarios
      where the VLAN header is both the inner and outer header for MACsec.
      
      The changes include:
      
      1. Adding MACsec offload operation for VLAN.
      2. Considering VLAN when accessing MACsec net device.
      3. Currently offloading MACsec when it's configured over VLAN with
      current MACsec TX steering rules would wrongly insert the MACsec sec tag
      after inserting the VLAN header. This resulted in an ETHERNET | SECTAG |
      VLAN packet when ETHERNET | VLAN | SECTAG is configured. The patche
      handles this issue when configuring steering rules.
      4. Adding MACsec rx_handler change support in case of a marked skb and a
      mismatch on the dst MAC address.
      
      Please review these changes and let me know if you have any feedback or
      concerns.
      
      Updates since v1:
      - Consult vlan_features when adding NETIF_F_HW_MACSEC.
      - Allow grep for the functions.
      - Add helper function to get the macsec operation to allow the compiler
        to make some choice.
      
      Updates since v2:
      - Don't use macros to allow direct navigattion from mdo functions to its
        implementation.
      - Make the vlan_get_macsec_ops argument a const.
      - Check if the specific mdo function is available before calling it.
      - Enable NETIF_F_HW_MACSEC by default when the lower device has it enabled
        and in case the lower device currently has NETIF_F_HW_MACSEC but disabled
        let the new vlan device also have it disabled.
      
      Updates since v3:
      - Split patch ("vlan: Add MACsec offload operations for VLAN interface")
        to prevent mixing generic vlan code changes with driver changes.
      - Add mdo_open, stop and stats to support drivers which have those.
      - Don't fail if macsec offload operations are available but a specific
        function is not, to support drivers which does not implement all
        macsec offload operations.
      - Don't call find_rx_sc twice in the same loop, instead save the result
        in a parameter and re-use it.
      - Completely remove _BUILD_VLAN_MACSEC_MDO macro, to prevent returning
        from a macro.
      - Reorder the functions inside struct macsec_ops to match the struct
        decleration.
      
       Updates since v4:
       - Change subject line of ("macsec: Add MACsec rx_handler change support") and adapt commit message.
       - Don't separate the new check in patch ("macsec: Add MACsec rx_handler change support")
         from the previous if/else if.
       - Drop"_found" from the parameter naming "rx_sc_found" and move the definition to
         the relevant block.
       - Remove "{}" since not needed around a single line.
      
       Updates since v5:
       - Consider promiscuous mode case.
      
       Updates since v6:
       - Use IS_ENABLED instead of checking for ifdef.
       - Don't add inline keywork in c files, let the compiler make its own decisions.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1cf3fe1c
    • Emeel Hakim's avatar
      macsec: Don't rely solely on the dst MAC address to identify destination MACsec device · 7661351a
      Emeel Hakim authored
      Offloading device drivers will mark offloaded MACsec SKBs with the
      corresponding SCI in the skb_metadata_dst so the macsec rx handler will
      know to which interface to divert those skbs, in case of a marked skb
      and a mismatch on the dst MAC address, divert the skb to the macsec
      net_device where the macsec rx_handler will be called to consider cases
      where relying solely on the dst MAC address is insufficient.
      
      One such instance is when using MACsec with a VLAN as an inner
      header, where the packet structure is ETHERNET | SECTAG | VLAN.
      In such a scenario, the dst MAC address in the ethernet header
      will correspond to the VLAN MAC address, resulting in a mismatch.
      Signed-off-by: default avatarEmeel Hakim <ehakim@nvidia.com>
      Reviewed-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7661351a
    • Emeel Hakim's avatar
      net/mlx5: Consider VLAN interface in MACsec TX steering rules · 765f974c
      Emeel Hakim authored
      Offloading MACsec when its configured over VLAN with current MACsec
      TX steering rules will wrongly insert MACsec sec tag after inserting
      the VLAN header leading to a ETHERNET | SECTAG | VLAN packet when
      ETHERNET | VLAN | SECTAG is configured.
      
      The above issue is due to adding the SECTAG by HW which is a later
      stage compared to the VLAN header insertion stage.
      
      Detect such a case and adjust TX steering rules to insert the
      SECTAG in the correct place by using reformat_param_0 field in
      the packet reformat to indicate the offset of SECTAG from end of
      the MAC header to account for VLANs in granularity of 4Bytes.
      Signed-off-by: default avatarEmeel Hakim <ehakim@nvidia.com>
      Reviewed-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      765f974c
    • Emeel Hakim's avatar
      net/mlx5: Support MACsec over VLAN · 4bba492b
      Emeel Hakim authored
      MACsec device may have a VLAN device on top of it.
      Detect MACsec state correctly under this condition,
      and return the correct net device accordingly.
      Signed-off-by: default avatarEmeel Hakim <ehakim@nvidia.com>
      Reviewed-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bba492b
    • Emeel Hakim's avatar
      net/mlx5: Enable MACsec offload feature for VLAN interface · 339ccec8
      Emeel Hakim authored
      Enable MACsec offload feature over VLAN by adding NETIF_F_HW_MACSEC
      to the device vlan_features.
      Signed-off-by: default avatarEmeel Hakim <ehakim@nvidia.com>
      Reviewed-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      339ccec8
    • Emeel Hakim's avatar
      vlan: Add MACsec offload operations for VLAN interface · abff3e5e
      Emeel Hakim authored
      Add support for MACsec offload operations for VLAN driver
      to allow offloading MACsec when VLAN's real device supports
      Macsec offload by forwarding the offload request to it.
      Signed-off-by: default avatarEmeel Hakim <ehakim@nvidia.com>
      Reviewed-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abff3e5e
    • David S. Miller's avatar
      Merge branch 'sctp-nested-flex-arrays' · e2598dbd
      David S. Miller authored
      Xin Long says:
      
      ====================
      sctp: fix a plenty of flexible-array-nested warnings
      
      Paolo noticed a compile warning in SCTP,
      
      ../net/sctp/stream_sched_fc.c: note: in included file (through ../include/net/sctp/sctp.h):
      ../include/net/sctp/structs.h:335:41: warning: array of flexible structures
      
      But not only this, there are actually quite a lot of such warnings in
      some SCTP structs. This patchset fixes most of warnings by deleting
      these nested flexible array members.
      
      After this patchset, there are still some warnings left:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        ./include/net/sctp/structs.h:1145:41: warning: nested flexible array
        ./include/uapi/linux/sctp.h:641:34: warning: nested flexible array
        ./include/uapi/linux/sctp.h:643:34: warning: nested flexible array
        ./include/uapi/linux/sctp.h:644:33: warning: nested flexible array
        ./include/uapi/linux/sctp.h:650:40: warning: nested flexible array
        ./include/uapi/linux/sctp.h:653:39: warning: nested flexible array
      
      the 1st is caused by __data[] in struct ip_options, not in SCTP;
      the others are in uapi, and we should not touch them.
      
      Note that instead of completely deleting it, we just leave it as a
      comment in the struct, signalling to the reader that we do expect
      such variable parameters over there, as Marcelo suggested.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2598dbd
    • Xin Long's avatar
      sctp: delete the nested flexible array payload · dbda0fba
      Xin Long authored
      This patch deletes the flexible-array payload[] from the structure
      sctp_datahdr to avoid some sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/socket.c: note: in included file (through include/net/sctp/structs.h, include/net/sctp/sctp.h):
        ./include/linux/sctp.h:230:29: warning: nested flexible array
      
      This member is not even used anywhere.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dbda0fba
    • Xin Long's avatar
      sctp: delete the nested flexible array hmac · 2ab399a9
      Xin Long authored
      This patch deletes the flexible-array hmac[] from the structure
      sctp_authhdr to avoid some sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/auth.c: note: in included file (through include/net/sctp/structs.h, include/net/sctp/sctp.h):
        ./include/linux/sctp.h:735:29: warning: nested flexible array
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ab399a9
    • Xin Long's avatar
      sctp: delete the nested flexible array peer_init · f97278ff
      Xin Long authored
      This patch deletes the flexible-array peer_init[] from the structure
      sctp_cookie to avoid some sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/sm_make_chunk.c: note: in included file (through include/net/sctp/sctp.h):
        ./include/net/sctp/structs.h:1588:28: warning: nested flexible array
        ./include/net/sctp/structs.h:343:28: warning: nested flexible array
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f97278ff
    • Xin Long's avatar
      sctp: delete the nested flexible array variable · 9789c1c6
      Xin Long authored
      This patch deletes the flexible-array variable[] from the structure
      sctp_sackhdr and sctp_errhdr to avoid some sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/sm_statefuns.c: note: in included file (through include/net/sctp/structs.h, include/net/sctp/sctp.h):
        ./include/linux/sctp.h:451:28: warning: nested flexible array
        ./include/linux/sctp.h:393:29: warning: nested flexible array
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9789c1c6
    • Xin Long's avatar
      sctp: delete the nested flexible array skip · 73175a04
      Xin Long authored
      This patch deletes the flexible-array skip[] from the structure
      sctp_ifwdtsn/fwdtsn_hdr to avoid some sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/stream_interleave.c: note: in included file (through include/net/sctp/structs.h, include/net/sctp/sctp.h):
        ./include/linux/sctp.h:611:32: warning: nested flexible array
        ./include/linux/sctp.h:628:33: warning: nested flexible array
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73175a04
    • Xin Long's avatar
      sctp: delete the nested flexible array params · add7370a
      Xin Long authored
      This patch deletes the flexible-array params[] from the structure
      sctp_inithdr, sctp_addiphdr and sctp_reconf_chunk to avoid some
      sparse warnings:
      
        # make C=2 CF="-Wflexible-array-nested" M=./net/sctp/
        net/sctp/input.c: note: in included file (through include/net/sctp/structs.h, include/net/sctp/sctp.h):
        ./include/linux/sctp.h:278:29: warning: nested flexible array
        ./include/linux/sctp.h:675:30: warning: nested flexible array
      
      This warning is reported if a structure having a flexible array
      member is included by other structures.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      add7370a
    • Jakub Kicinski's avatar
      Merge branch 'net-extend-drop-reasons' · 2f3a247c
      Jakub Kicinski authored
      Johannes Berg says:
      
      ====================
      net: extend drop reasons
      
      Here's v4 of the extended drop reasons, with fixes to kernel-doc
      and checkpatch.
      ====================
      
      Link: https://lore.kernel.org/r/20230419125254.20789-1-johannes@sipsolutions.netSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2f3a247c
    • Johannes Berg's avatar
      mac80211: use the new drop reasons infrastructure · baa951a1
      Johannes Berg authored
      It can be really hard to analyse or debug why packets are
      going missing in mac80211, so add the needed infrastructure
      to use use the new per-subsystem drop reasons.
      
      We actually use two drop reason subsystems here because of
      the different handling of frames that are dropped but still
      go to monitor for old versions of hostapd, and those that
      are just completely unusable (e.g. crypto failed.)
      
      Annotate a few reasons here just to illustrate this, we'll
      need to go through and annotate more of them later.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      baa951a1
    • Johannes Berg's avatar
      net: extend drop reasons for multiple subsystems · 071c0fc6
      Johannes Berg authored
      Extend drop reasons to make them usable by subsystems
      other than core by reserving the high 16 bits for a
      new subsystem ID, of which 0 of course is used for the
      existing reasons immediately.
      
      To still be able to have string reasons, restructure
      that code a bit to make the loopup under RCU, the only
      user of this (right now) is drop_monitor.
      
      Link: https://lore.kernel.org/netdev/00659771ed54353f92027702c5bbb84702da62ce.camel@sipsolutions.netSigned-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      071c0fc6
    • Johannes Berg's avatar
      net: move dropreason.h to dropreason-core.h · 5b8285cc
      Johannes Berg authored
      This will, after the next patch, hold only the core
      drop reasons and minimal infrastructure. Fix a small
      kernel-doc issue while at it, to avoid the move
      triggering a checker.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      5b8285cc
    • Mahesh Bandewar's avatar
      ipv6: add icmpv6_error_anycast_as_unicast for ICMPv6 · 7ab75456
      Mahesh Bandewar authored
      ICMPv6 error packets are not sent to the anycast destinations and this
      prevents things like traceroute from working. So create a setting similar
      to ECHO when dealing with Anycast sources (icmpv6_echo_ignore_anycast).
      Signed-off-by: default avatarMahesh Bandewar <maheshb@google.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Reviewed-by: default avatarMaciej Żenczykowski <maze@google.com>
      Link: https://lore.kernel.org/r/20230419013238.2691167-1-maheshb@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7ab75456
    • Jakub Kicinski's avatar
      Merge branch 'ethtool-mm-api-consolidation' · b7b871f5
      Jakub Kicinski authored
      Vladimir Oltean says:
      
      ====================
      ethtool mm API consolidation
      
      This series consolidates the behavior of the 2 drivers that implement
      the ethtool MAC Merge layer by making NXP ENETC commit its preemptible
      traffic classes to hardware only when MM TX is active (same as Ocelot).
      
      Then, after resolving an issue with the ENETC driver, it restricts user
      space from entering 2 states which don't make sense:
      
      - pmac-enabled off tx-enabled on  verify-enabled *
      - pmac-enabled *   tx-enabled off verify-enabled on
      
      Then, it introduces a selftest (ethtool_mm.sh) which puts everything
      together and tests all valid configurations known to me.
      
      This is simultaneously the v2 of "[PATCH net-next 0/2] ethtool mm API
      improvements":
      https://lore.kernel.org/netdev/20230415173454.3970647-1-vladimir.oltean@nxp.com/
      which had caused some problems to openlldp. Those were solved in the
      meantime, see:
      https://github.com/intel/openlldp/commit/11171b474f6f3cbccac5d608b7f26b32ff72c651
      
      and of "[RFC PATCH net-next] selftests: forwarding: add a test for MAC
      Merge layer":
      https://lore.kernel.org/netdev/20230210221243.228932-1-vladimir.oltean@nxp.com/
      ====================
      
      Link: https://lore.kernel.org/r/20230418111459.811553-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b7b871f5
    • Vladimir Oltean's avatar
      selftests: forwarding: add a test for MAC Merge layer · e6991384
      Vladimir Oltean authored
      The MAC Merge layer (IEEE 802.3-2018 clause 99) does all the heavy
      lifting for Frame Preemption (IEEE 802.1Q-2018 clause 6.7.2), a TSN
      feature for minimizing latency.
      
      Preemptible traffic is different on the wire from normal traffic in
      incompatible ways. If we send a preemptible packet and the link partner
      doesn't support preemption, it will drop it as an error frame and we
      will never know. The MAC Merge layer has a control plane of its own,
      which can be manipulated (using ethtool) in order to negotiate this
      capability with the link partner (through LLDP).
      
      Actually the TLV format for LLDP solves this problem only partly,
      because both partners only advertise:
      - if they support preemption (RX and TX)
      - if they have enabled preemption (TX)
      so we cannot tell the link partner what to do - we cannot force it to
      enable reception of our preemptible packets.
      
      That is fully solved by the verification feature, where the local device
      generates some small probe frames which look like preemptible frames
      with no useful content, and the link partner is obliged to respond to
      them if it supports the standard. If the verification times out, we know
      that preemption isn't active in our TX direction on the link.
      
      Having clarified the definition, this selftest exercises the manual
      (ethtool) configuration path of 2 link partners (with and without
      verification), and the LLDP code path, using the openlldp project.
      
      The test also verifies the TX activity of the MAC Merge layer by
      sending traffic through a traffic class configured as preemptible
      (using mqprio). There isn't a good way to make this really portable
      (user space cannot find out how many traffic classes there are for
      a device), but I chose num_tc 4 here, that should work reasonably well.
      I also know that some devices (stmmac) only permit TXQ0 to be
      preemptible, so this is why PREEMPTIBLE_PRIO was strategically chosen
      as 0. Even if other hardware is more configurable, this test should
      cover the baseline.
      
      This is not really a "forwarding" selftest, but I put it near the other
      "ethtool" selftests.
      
      $ ./ethtool_mm.sh eno0 swp0
      TEST: Manual configuration with verification: eno0 to swp0          [ OK ]
      TEST: Manual configuration with verification: swp0 to eno0          [ OK ]
      TEST: Manual configuration without verification: eno0 to swp0       [ OK ]
      TEST: Manual configuration without verification: swp0 to eno0       [ OK ]
      TEST: Manual configuration with failed verification: eno0 to swp0   [ OK ]
      TEST: Manual configuration with failed verification: swp0 to eno0   [ OK ]
      TEST: LLDP                                                          [ OK ]
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e6991384
    • Vladimir Oltean's avatar
      selftests: forwarding: introduce helper for standard ethtool counters · b5bf7126
      Vladimir Oltean authored
      Counters for the MAC Merge layer and preemptible MAC have standardized
      so far on using structured ethtool stats as opposed to the driver
      specific names and meanings.
      
      Benefit from that rare opportunity and introduce a helper to lib.sh for
      querying standardized counters, in the hope that these will take off for
      other uses as well.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b5bf7126
    • Petr Machata's avatar
      selftests: forwarding: generalize bail_on_lldpad from mlxsw · 8fcac792
      Petr Machata authored
      mlxsw selftests often invoke a bail_on_lldpad() helper to make sure LLDPAD
      is not running, to prevent conflicts between the QoS configuration applied
      through TC or DCB command line tool, and the DCB configuration that LLDPAD
      might apply. This helper might be useful to others. Move the function to
      lib.sh, and parameterize to make reusable in other contexts.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8fcac792
    • Petr Machata's avatar
      selftests: forwarding: sch_tbf_*: Add a pre-run hook · 54e906f1
      Petr Machata authored
      The driver-specific wrappers of these selftests invoke bail_on_lldpad to
      make sure that LLDPAD doesn't trample the configuration. The function
      bail_on_lldpad is going to move to lib.sh in the next patch. With that, it
      won't be visible for the wrappers before sourcing the framework script. And
      after sourcing it, it is too late: the selftest will have run by then.
      
      One option might be to source NUM_NETIFS=0 lib.sh from the wrapper, but
      even if that worked (it might, it might not), that seems cumbersome. lib.sh
      is doing fair amount of stuff, and even if it works today, it does not look
      particularly solid as a solution.
      
      Instead, introduce a hook, sch_tbf_pre_hook(), that when available, gets
      invoked. Move the bail to the hook.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      54e906f1
    • Vladimir Oltean's avatar
      net: ethtool: mm: sanitize some UAPI configurations · 35b288d6
      Vladimir Oltean authored
      The verify-enabled boolean (ETHTOOL_A_MM_VERIFY_ENABLED) was intended to
      be a sub-setting of tx-enabled (ETHTOOL_A_MM_TX_ENABLED). IOW, MAC Merge
      TX can be enabled with or without verification, but verification with TX
      disabled makes no sense.
      
      The pmac-enabled boolean (ETHTOOL_A_MM_PMAC_ENABLED) was intended to be
      a global toggle from an API perspective, whereas tx-enabled just handles
      the TX direction. IOW, the pMAC can be enabled with or without TX, but
      it doesn't make sense to enable TX if the pMAC is not enabled.
      
      Add two checks which sanitize and reject these invalid cases.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      35b288d6
    • Vladimir Oltean's avatar
      net: enetc: include MAC Merge / FP registers in register dump · 16a2c763
      Vladimir Oltean authored
      These have been useful in debugging various problems related to frame
      preemption, so make them available through ethtool --register-dump for
      later too.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      16a2c763
    • Vladimir Oltean's avatar
      net: enetc: only commit preemptible TCs to hardware when MM TX is active · 82714539
      Vladimir Oltean authored
      This was left as TODO in commit 01e23b2b ("net: enetc: add support
      for preemptible traffic classes") since it's relatively complicated.
      
      Where this makes a difference is with a configuration as follows:
      
      ethtool --set-mm eno0 pmac-enabled on tx-enabled on verify-enabled on
      
      Preemptible packets should only be sent when the MAC Merge TX direction
      becomes active (i.o.w. when the verification process succeeds, aka when
      the link partner confirms it can process preemptible traffic). But the
      tc qdisc with the preemptible traffic classes is offloaded completely
      asynchronously w.r.t. the MM becoming active.
      
      The ENETC manual does suggest that this should be handled in the driver:
      "On startup, software should wait for the verification process to
      complete (MMCSR[VSTS]=011) before initiating traffic".
      
      Adding the necessary logic allows future selftests to uphold the claim
      that an inactive or disabled MAC Merge layer should never send data
      packets through the pMAC.
      
      This change moves enetc_set_ptcfpr() from enetc.c to enetc_ethtool.c,
      where its only caller is now - enetc_mm_commit_preemptible_tcs().
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      82714539
    • Vladimir Oltean's avatar
      net: enetc: report mm tx-active based on tx-enabled and verify-status · 153b5b1d
      Vladimir Oltean authored
      The MMCSR register contains 2 fields with overlapping meaning:
      
      - LPA (Local preemption active):
      This read-only status bit indicates whether preemption is active for
      this port. This bit will be set if preemption is both enabled and has
      completed the verification process.
      - TXSTS (Merge status):
      This read-only status field provides the state of the MAC Merge sublayer
      transmit status as defined in IEEE Std 802.3-2018 Clause 99.
      00 Transmit preemption is inactive
      01 Transmit preemption is active
      10 Reserved
      11 Reserved
      
      However none of these 2 fields offer reliable reporting to software.
      
      When connecting ENETC to a link partner which is not capable of Frame
      Preemption, the expectation is that ENETC's verification should fail
      (VSTS=4) and its MM TX direction should be inactive (LPA=0, TXSTS=00)
      even though the MM TX is enabled (ME=1). But surprise, the LPA bit of
      MMCSR stays set even if VSTS=4 and ME=1.
      
      OTOH, the TXSTS field has the opposite problem. I cannot get its value
      to change from 0, even when connecting to a link partner capable of
      frame preemption, which does respond to its verification frames (ME=1
      and VSTS=3, "SUCCEEDED").
      
      The only option with such buggy hardware seems to be to reimplement the
      formula for calculating tx-active in software, which is for tx-enabled
      to be true, and for the verify-status to be either SUCCEEDED, or
      DISABLED.
      
      Without reliable tx-active reporting, we have no good indication when
      to commit the preemptible traffic classes to hardware, which makes it
      possible (but not desirable) to send preemptible traffic to a link
      partner incapable of receiving it. However, currently we do not have the
      logic to wait for TX to be active yet, so the impact is limited.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      153b5b1d
    • Vladimir Oltean's avatar
      net: enetc: fix MAC Merge layer remaining enabled until a link down event · 59be75db
      Vladimir Oltean authored
      Current enetc_set_mm() is designed to set the priv->active_offloads bit
      ENETC_F_QBU for enetc_mm_link_state_update() to act on, but if the link
      is already up, it modifies the ENETC_MMCSR_ME ("Merge Enable") bit
      directly.
      
      The problem is that it only *sets* ENETC_MMCSR_ME if the link is up, it
      doesn't *clear* it if needed. So subsequent enetc_get_mm() calls still
      see tx-enabled as true, up until a link down event, which is when
      enetc_mm_link_state_update() will get called.
      
      This is not a functional issue as far as I can assess. It has only come
      up because I'd like to uphold a simple API rule in core ethtool code:
      the pMAC cannot be disabled if TX is going to be enabled. Currently,
      the fact that TX remains enabled for longer than expected (after the
      enetc_set_mm() call that disables it) is going to violate that rule,
      which is how it was caught.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      59be75db
    • Slark Xiao's avatar
      wwan: core: add print for wwan port attach/disconnect · 787e6144
      Slark Xiao authored
      Refer to USB serial device or net device, there is a notice to
      let end user know the status of device, like attached or
      disconnected. Add attach/disconnect print for wwan device as
      well.
      Signed-off-by: default avatarSlark Xiao <slark_xiao@163.com>
      Reviewed-by: default avatarLoic Poulain <loic.poulain@linaro.org>
      Link: https://lore.kernel.org/r/20230420023617.3919569-1-slark_xiao@163.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      787e6144
    • Jakub Kicinski's avatar
      net: skbuff: update and rename __kfree_skb_defer() · 8fa66e4a
      Jakub Kicinski authored
      __kfree_skb_defer() uses the old naming where "defer" meant
      slab bulk free/alloc APIs. In the meantime we also made
      __kfree_skb_defer() feed the per-NAPI skb cache, which
      implies bulk APIs. So take away the 'defer' and add 'napi'.
      
      While at it add a drop reason. This only matters on the
      tx_action path, if the skb has a frag_list. But getting
      rid of a SKB_DROP_REASON_NOT_SPECIFIED seems like a net
      benefit so why not.
      Reviewed-by: default avatarAlexander Lobakin <aleksander.lobakin@intel.com>
      Link: https://lore.kernel.org/r/20230420020005.815854-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8fa66e4a
    • Jakub Kicinski's avatar
      eth: mlx5: avoid iterator use outside of a loop · 61718206
      Jakub Kicinski authored
      Fix the following warning about risky iterator use:
      
      drivers/net/ethernet/mellanox/mlx5/core/eq.c:1010 mlx5_comp_irq_get_affinity_mask() warn: iterator used outside loop: 'eq'
      Acked-by: default avatarSaeed Mahameed <saeed@kernel.org>
      Link: https://lore.kernel.org/r/20230420015802.815362-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      61718206
    • Simon Horman's avatar
      flow_dissector: Address kdoc warnings · 8c966a10
      Simon Horman authored
      Address a number of warnings flagged by
      ./scripts/kernel-doc -none include/net/flow_dissector.h
      
       include/net/flow_dissector.h:23: warning: Function parameter or member 'addr_type' not described in 'flow_dissector_key_control'
       include/net/flow_dissector.h:23: warning: Function parameter or member 'flags' not described in 'flow_dissector_key_control'
       include/net/flow_dissector.h:46: warning: Function parameter or member 'padding' not described in 'flow_dissector_key_basic'
       include/net/flow_dissector.h:145: warning: Function parameter or member 'tipckey' not described in 'flow_dissector_key_addrs'
       include/net/flow_dissector.h:157: warning: cannot understand function prototype: 'struct flow_dissector_key_arp '
       include/net/flow_dissector.h:171: warning: cannot understand function prototype: 'struct flow_dissector_key_ports '
       include/net/flow_dissector.h:203: warning: cannot understand function prototype: 'struct flow_dissector_key_icmp '
      
      Also improve indentation on adjacent lines to those changed
      to address the above.
      
      No functional changes intended.
      Signed-off-by: default avatarSimon Horman <horms@kernel.org>
      Link: https://lore.kernel.org/r/20230419-flow-dissector-kdoc-v1-1-1aa0cca1118b@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      8c966a10
    • Jakub Kicinski's avatar
      page_pool: unlink from napi during destroy · dd64b232
      Jakub Kicinski authored
      Jesper points out that we must prevent recycling into cache
      after page_pool_destroy() is called, because page_pool_destroy()
      is not synchronized with recycling (some pages may still be
      outstanding when destroy() gets called).
      
      I assumed this will not happen because NAPI can't be scheduled
      if its page pool is being destroyed. But I missed the fact that
      NAPI may get reused. For instance when user changes ring configuration
      driver may allocate a new page pool, stop NAPI, swap, start NAPI,
      and then destroy the old pool. The NAPI is running so old page
      pool will think it can recycle to the cache, but the consumer
      at that point is the destroy() path, not NAPI.
      
      To avoid extra synchronization let the drivers do "unlinking"
      during the "swap" stage while NAPI is indeed disabled.
      
      Fixes: 8c48eea3 ("page_pool: allow caching from safely localized NAPI")
      Reported-by: default avatarJesper Dangaard Brouer <jbrouer@redhat.com>
      Link: https://lore.kernel.org/all/e8df2654-6a5b-3c92-489d-2fe5e444135f@redhat.com/Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Link: https://lore.kernel.org/r/20230419182006.719923-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      dd64b232
    • Arnd Bergmann's avatar
      net: phy: fix circular LEDS_CLASS dependencies · 4bb7aac7
      Arnd Bergmann authored
      The CONFIG_PHYLIB symbol is selected by a number of device drivers that
      need PHY support, but it now has a dependency on CONFIG_LEDS_CLASS,
      which may not be enabled, causing build failures.
      
      Avoid the risk of missing and circular dependencies by guarding the
      phylib LED support itself in another Kconfig symbol that can only be
      enabled if the dependency is met.
      
      This could be made a hidden symbol and always enabled when both CONFIG_OF
      and CONFIG_LEDS_CLASS are reachable from the phylib, but there may be an
      advantage in having users see this option when they have a misconfigured
      kernel without built-in LED support.
      
      Fixes: 01e5b728 ("net: phy: Add a binding for PHY LEDs")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20230420084624.3005701-1-arnd@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4bb7aac7
  2. 20 Apr, 2023 6 commits
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 681c5b51
      Jakub Kicinski authored
      Adjacent changes:
      
      net/mptcp/protocol.h
        63740448 ("mptcp: fix accept vs worker race")
        2a6a870e ("mptcp: stops worker on unaccepted sockets at listener close")
        ddb1a072 ("mptcp: move first subflow allocation at mpc access time")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      681c5b51
    • Toke Høiland-Jørgensen's avatar
      wifi: ath9k: Don't mark channelmap stack variable read-only in ath9k_mci_update_wlan_channels() · 0f2a4af2
      Toke Høiland-Jørgensen authored
      This partially reverts commit e161d4b6.
      
      Turns out the channelmap variable is not actually read-only, it's modified
      through the MCI_GPM_CLR_CHANNEL_BIT() macro further down in the function,
      so making it read-only causes page faults when that code is hit.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=217183
      Link: https://lore.kernel.org/r/20230413214118.153781-1-toke@toke.dk
      Fixes: e161d4b6 ("wifi: ath9k: Make arrays prof_prio and channelmap static const")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0f2a4af2
    • Linus Torvalds's avatar
      Merge tag 'rust-fixes-6.3' of https://github.com/Rust-for-Linux/linux · 6a66fdd2
      Linus Torvalds authored
      Pull Rust fixes from Miguel Ojeda:
       "Most of these are straightforward.
      
        The last one is more complex, but it only touches Rust + GCC builds
        which are for the moment best-effort.
      
         - Code: Missing 'extern "C"' fix.
      
         - Scripts: 'is_rust_module.sh' and 'generate_rust_analyzer.py' fixes.
      
         - A couple trivial fixes
      
         - Build: Rust + GCC build fix and 'grep' warning fix"
      
      * tag 'rust-fixes-6.3' of https://github.com/Rust-for-Linux/linux:
        rust: allow to use INIT_STACK_ALL_ZERO
        rust: fix regexp in scripts/is_rust_module.sh
        rust: build: Fix grep warning
        scripts: generate_rust_analyzer: Handle sub-modules with no Makefile
        rust: kernel: Mark rust_fmt_argument as extern "C"
        rust: sort uml documentation arch support table
        rust: str: fix requierments->requirements typo
      6a66fdd2
    • Linus Torvalds's avatar
      Merge tag 'net-6.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 23309d60
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from netfilter and bpf.
      
        There are a few fixes for new code bugs, including the Mellanox one
        noted in the last networking pull. No known regressions outstanding.
      
        Current release - regressions:
      
         - sched: clear actions pointer in miss cookie init fail
      
         - mptcp: fix accept vs worker race
      
         - bpf: fix bpf_arch_text_poke() with new_addr == NULL on s390
      
         - eth: bnxt_en: fix a possible NULL pointer dereference in unload
           path
      
         - eth: veth: take into account peer device for
           NETDEV_XDP_ACT_NDO_XMIT xdp_features flag
      
        Current release - new code bugs:
      
         - eth: revert "net/mlx5: Enable management PF initialization"
      
        Previous releases - regressions:
      
         - netfilter: fix recent physdev match breakage
      
         - bpf: fix incorrect verifier pruning due to missing register
           precision taints
      
         - eth: virtio_net: fix overflow inside xdp_linearize_page()
      
         - eth: cxgb4: fix use after free bugs caused by circular dependency
           problem
      
         - eth: mlxsw: pci: fix possible crash during initialization
      
        Previous releases - always broken:
      
         - sched: sch_qfq: prevent slab-out-of-bounds in qfq_activate_agg
      
         - netfilter: validate catch-all set elements
      
         - bridge: don't notify FDB entries with "master dynamic"
      
         - eth: bonding: fix memory leak when changing bond type to ethernet
      
         - eth: i40e: fix accessing vsi->active_filters without holding lock
      
        Misc:
      
         - Mat is back as MPTCP co-maintainer"
      
      * tag 'net-6.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (33 commits)
        net: bridge: switchdev: don't notify FDB entries with "master dynamic"
        Revert "net/mlx5: Enable management PF initialization"
        MAINTAINERS: Resume MPTCP co-maintainer role
        mailmap: add entries for Mat Martineau
        e1000e: Disable TSO on i219-LM card to increase speed
        bnxt_en: fix free-runnig PHC mode
        net: dsa: microchip: ksz8795: Correctly handle huge frame configuration
        bpf: Fix incorrect verifier pruning due to missing register precision taints
        hamradio: drop ISA_DMA_API dependency
        mlxsw: pci: Fix possible crash during initialization
        mptcp: fix accept vs worker race
        mptcp: stops worker on unaccepted sockets at listener close
        net: rpl: fix rpl header size calculation
        net: vmxnet3: Fix NULL pointer dereference in vmxnet3_rq_rx_complete()
        bonding: Fix memory leak when changing bond type to Ethernet
        veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features flag
        mlxfw: fix null-ptr-deref in mlxfw_mfa2_tlv_next()
        bnxt_en: Fix a possible NULL pointer dereference in unload path
        bnxt_en: Do not initialize PTP on older P3/P4 chips
        netfilter: nf_tables: tighten netlink attribute requirements for catch-all elements
        ...
      23309d60
    • Zhengchao Shao's avatar
      net: libwx: fix memory leak in wx_setup_rx_resources · e315e7b8
      Zhengchao Shao authored
      When wx_alloc_page_pool() failed in wx_setup_rx_resources(), it doesn't
      release DMA buffer. Add dma_free_coherent() in the error path to release
      the DMA buffer.
      
      Fixes: 850b9711 ("net: libwx: Allocate Rx and Tx resources")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Link: https://lore.kernel.org/r/20230418065450.2268522-1-shaozhengchao@huawei.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      e315e7b8
    • Vladimir Oltean's avatar
      net: bridge: switchdev: don't notify FDB entries with "master dynamic" · 927cdea5
      Vladimir Oltean authored
      There is a structural problem in switchdev, where the flag bits in
      struct switchdev_notifier_fdb_info (added_by_user, is_local etc) only
      represent a simplified / denatured view of what's in struct
      net_bridge_fdb_entry :: flags (BR_FDB_ADDED_BY_USER, BR_FDB_LOCAL etc).
      Each time we want to pass more information about struct
      net_bridge_fdb_entry :: flags to struct switchdev_notifier_fdb_info
      (here, BR_FDB_STATIC), we find that FDB entries were already notified to
      switchdev with no regard to this flag, and thus, switchdev drivers had
      no indication whether the notified entries were static or not.
      
      For example, this command:
      
      ip link add br0 type bridge && ip link set swp0 master br0
      bridge fdb add dev swp0 00:01:02:03:04:05 master dynamic
      
      has never worked as intended with switchdev. It causes a struct
      net_bridge_fdb_entry to be passed to br_switchdev_fdb_notify() which has
      a single flag set: BR_FDB_ADDED_BY_USER.
      
      This is further passed to the switchdev notifier chain, where interested
      drivers have no choice but to assume this is a static (does not age) and
      sticky (does not migrate) FDB entry. So currently, all drivers offload
      it to hardware as such, as can be seen below ("offload" is set).
      
      bridge fdb get 00:01:02:03:04:05 dev swp0 master
      00:01:02:03:04:05 dev swp0 offload master br0
      
      The software FDB entry expires $ageing_time centiseconds after the
      kernel last sees a packet with this MAC SA, and the bridge notifies its
      deletion as well, so it eventually disappears from hardware too.
      
      This is a problem, because it is actually desirable to start offloading
      "master dynamic" FDB entries correctly - they should expire $ageing_time
      centiseconds after the *hardware* port last sees a packet with this
      MAC SA - and this is how the current incorrect behavior was discovered.
      With an offloaded data plane, it can be expected that software only sees
      exception path packets, so an otherwise active dynamic FDB entry would
      be aged out by software sooner than it should.
      
      With the change in place, these FDB entries are no longer offloaded:
      
      bridge fdb get 00:01:02:03:04:05 dev swp0 master
      00:01:02:03:04:05 dev swp0 master br0
      
      and this also constitutes a better way (assuming a backport to stable
      kernels) for user space to determine whether the kernel has the
      capability of doing something sane with these or not.
      
      As opposed to "master dynamic" FDB entries, on the current behavior of
      which no one currently depends on (which can be deduced from the lack of
      kselftests), Ido Schimmel explains that entries with the "extern_learn"
      flag (BR_FDB_ADDED_BY_EXT_LEARN) should still be notified to switchdev,
      since the spectrum driver listens to them (and this is kind of okay,
      because although they are treated identically to "static", they are
      expected to not age, and to roam).
      
      Fixes: 6b26b51b ("net: bridge: Add support for notifying devices about FDB add/del")
      Link: https://lore.kernel.org/netdev/20230327115206.jk5q5l753aoelwus@skbuf/Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Tested-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Link: https://lore.kernel.org/r/20230418155902.898627-1-vladimir.oltean@nxp.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      927cdea5