1. 22 Jun, 2021 25 commits
  2. 21 Jun, 2021 15 commits
    • Kees Cook's avatar
      ibmvnic: Use strscpy() instead of strncpy() · ef2c3dda
      Kees Cook authored
      Since these strings are expected to be NUL-terminated and the buffers
      are exactly sized (in vnic_client_data_len()) with no padding, strncpy()
      can be safely replaced with strscpy() here, as strncpy() on
      NUL-terminated string is considered deprecated[1]. This has the
      side-effect of silencing a -Warray-bounds warning due to the compiler
      being confused about the vlcd incrementing:
      
      In file included from ./include/linux/string.h:253,
                       from ./include/linux/bitmap.h:10,
                       from ./include/linux/cpumask.h:12,
                       from ./include/linux/mm_types_task.h:14,
                       from ./include/linux/mm_types.h:5,
                       from ./include/linux/buildid.h:5,
                       from ./include/linux/module.h:14,
                       from drivers/net/ethernet/ibm/ibmvnic.c:35:
      In function '__fortify_strncpy',
          inlined from 'vnic_add_client_data' at drivers/net/ethernet/ibm/ibmvnic.c:3919:2:
      ./include/linux/fortify-string.h:39:30: warning: '__builtin_strncpy' offset 12 from the object at 'v
      lcd' is out of the bounds of referenced subobject 'name' with type 'char[]' at offset 12 [-Warray-bo
      unds]
         39 | #define __underlying_strncpy __builtin_strncpy
            |                              ^
      ./include/linux/fortify-string.h:51:9: note: in expansion of macro '__underlying_strncpy'
         51 |  return __underlying_strncpy(p, q, size);
            |         ^~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/ibm/ibmvnic.c: In function 'vnic_add_client_data':
      drivers/net/ethernet/ibm/ibmvnic.c:3883:7: note: subobject 'name' declared here
       3883 |  char name[];
            |       ^~~~
      
      [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
      
      Cc: Dany Madden <drt@linux.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
      Cc: Thomas Falcon <tlfalcon@linux.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Cc: netdev@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef2c3dda
    • Guillaume Nault's avatar
      net: handle ARPHRD_IP6GRE in dev_is_mac_header_xmit() · a3fa449f
      Guillaume Nault authored
      Similar to commit 3b707c30 ("net: dev_is_mac_header_xmit() true for
      ARPHRD_RAWIP"), add ARPHRD_IP6GRE to dev_is_mac_header_xmit(), to make
      ip6gre compatible with act_mirred and __bpf_redirect().
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3fa449f
    • Boris Sukholitko's avatar
      Revert "net/sched: cls_flower: Remove match on n_proto" · 6d551617
      Boris Sukholitko authored
      This reverts commit 0dca2c74.
      
      The commit in question breaks hardware offload of flower filters.
      
      Quoting Vladimir Oltean <olteanv@gmail.com>:
      
       fl_hw_replace_filter() and fl_reoffload() create a struct
       flow_cls_offload with a rule->match.mask member derived from the mask
       of the software classifier: &f->mask->key - that same mask that is used
       for initializing the flow dissector keys, and the one from which Boris
       removed the basic.n_proto member because it was bothering him.
      Reported-by: default avatarVadym Kochan <vadym.kochan@plvision.eu>
      Signed-off-by: default avatarBoris Sukholitko <boris.sukholitko@broadcom.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d551617
    • Esben Haabendal's avatar
      net: ll_temac: Remove left-over debug message · ce03b94b
      Esben Haabendal authored
      Fixes: f6396341 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY")
      Signed-off-by: default avatarEsben Haabendal <esben@geanix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce03b94b
    • Yejune Deng's avatar
      net: add pf_family_names[] for protocol family · fe0bdbde
      Yejune Deng authored
      Modify the pr_info content from int to char * in sock_register() and
      sock_unregister(), this looks more readable.
      
      Fixed build error in ARCH=sparc64.
      Signed-off-by: default avatarYejune Deng <yejune.deng@gmail.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe0bdbde
    • David S. Miller's avatar
      Merge branch 'ingenic-fixes' · c829de39
      David S. Miller authored
      Zhou Yanjie says:
      
      ====================
      Fix for Ingenic MAC support.
      
      1.Remove the unexpected "snps,dwmac" item in the example.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c829de39
    • 周琰杰 (Zhou Yanjie)'s avatar
      dt-bindings: dwmac: Remove unexpected item. · 19e068b1
      周琰杰 (Zhou Yanjie) authored
      Remove the unexpected "snps,dwmac" item in the example.
      
      Fixes: 3b840106 ("dt-bindings: dwmac: Add bindings for new Ingenic SoCs.")
      Signed-off-by: default avatar周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19e068b1
    • Christophe JAILLET's avatar
      net: hns3: Fix a memory leak in an error handling path in 'hclge_handle_error_info_log()' · b40d7af7
      Christophe JAILLET authored
      If this 'kzalloc()' fails we must free some resources as in all the other
      error handling paths of this function.
      
      Fixes: 2e2deee7 ("net: hns3: add the RAS compatibility adaptation solution")
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Reviewed-by: default avatarJiaran Zhang <zhangjiaran@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b40d7af7
    • David S. Miller's avatar
      Merge branch 'fec-tx' · ebe9d9eb
      David S. Miller authored
      Joakim Zhang says:
      
      ====================
      net: fec: fix TX bandwidth fluctuations
      
      This patch set intends to fix TX bandwidth fluctuations, any feedback would be appreciated.
      
      ---
      ChangeLogs:
      	V1: remove RFC tag, RFC discussions please turn to below:
      	    https://lore.kernel.org/lkml/YK0Ce5YxR2WYbrAo@lunn.ch/T/
      	V2: change functions to be static in this patch set. And add the
      	t-b tag.
      	V3: fix sparse warining: ntohs()->htons()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebe9d9eb
    • Fugang Duan's avatar
      net: fec: add ndo_select_queue to fix TX bandwidth fluctuations · 52c4a1a8
      Fugang Duan authored
      As we know that AVB is enabled by default, and the ENET IP design is
      queue 0 for best effort, queue 1&2 for AVB Class A&B. Bandwidth of each
      queue 1&2 set in driver is 50%, TX bandwidth fluctuated when selecting
      tx queues randomly with FEC_QUIRK_HAS_AVB quirk available.
      
      This patch adds ndo_select_queue callback to select queues for
      transmitting to fix this issue. It will always return queue 0 if this is
      not a vlan packet, and return queue 1 or 2 based on priority of vlan
      packet.
      
      You may complain that in fact we only use single queue for trasmitting
      if we are not targeted to VLAN. Yes, but seems we have no choice, since
      AVB is enabled when the driver probed, we can't switch this feature
      dynamicly. After compare multiple queues to single queue, TX throughput
      almost no improvement.
      
      One way we can implemet is to configure the driver to multiple queues
      with Round-robin scheme by default. Then add ndo_setup_tc callback to
      enable/disable AVB feature for users. Unfortunately, ENET AVB IP seems
      not follow the standard 802.1Qav spec. We only can program
      DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction. And idle
      slope is restricted to certain valus (a total of 19). It's far away from
      CBS QDisc implemented in Linux TC framework. If you strongly suggest to do
      this, I think we only can support limited numbers of bandwidth and reject
      others, but it's really urgly and wried.
      
      With this patch, VLAN tagged packets route to queue 0/1/2 based on vlan
      priority; VLAN untagged packets route to queue 0.
      Tested-by: default avatarFrieder Schrempf <frieder.schrempf@kontron.de>
      Reported-by: default avatarFrieder Schrempf <frieder.schrempf@kontron.de>
      Signed-off-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52c4a1a8
    • Joakim Zhang's avatar
      net: fec: add FEC_QUIRK_HAS_MULTI_QUEUES represents i.MX6SX ENET IP · 471ff445
      Joakim Zhang authored
      Frieder Schrempf reported a TX throuthput issue [1], it happens quite often
      that the measured bandwidth in TX direction drops from its expected/nominal
      value to something like ~50% (for 100M) or ~67% (for 1G) connections.
      
      [1] https://lore.kernel.org/linux-arm-kernel/421cc86c-b66f-b372-32f7-21e59f9a98bc@kontron.de/
      
      The issue becomes clear after digging into it, Net core would select
      queues when transmitting packets. Since FEC have not impletemented
      ndo_select_queue callback yet, so it will call netdev_pick_tx to select
      queues randomly.
      
      For i.MX6SX ENET IP with AVB support, driver default enables this
      feature. According to the setting of QOS/RCMRn/DMAnCFG registers, AVB
      configured to Credit-based scheme, 50% bandwidth of each queue 1&2.
      
      With below tests let me think more:
      1) With FEC_QUIRK_HAS_AVB quirk, can reproduce TX bandwidth fluctuations issue.
      2) Without FEC_QUIRK_HAS_AVB quirk, can't reproduce TX bandwidth fluctuations issue.
      
      The related difference with or w/o FEC_QUIRK_HAS_AVB quirk is that, whether we
      program FTYPE field of TxBD or not. As I describe above, AVB feature is
      enabled by default. With FEC_QUIRK_HAS_AVB quirk, frames in queue 0
      marked as non-AVB, and frames in queue 1&2 marked as AVB Class A&B. It's
      unreasonable if frames in queue 1&2 are not required to be time-sensitive.
      So when Net core select tx queues ramdomly, Credit-based scheme would work
      and lead to TX bandwidth fluctuated. On the other hand, w/o
      FEC_QUIRK_HAS_AVB quirk, frames in queue 1&2 are all marked as non-AVB, so
      Credit-based scheme would not work.
      
      Till now, how can we fix this TX throughput issue? Yes, please remove
      FEC_QUIRK_HAS_AVB quirk if you suffer it from time-nonsensitive networking.
      However, this quirk is used to indicate i.MX6SX, other setting depends
      on it. So this patch adds a new quirk FEC_QUIRK_HAS_MULTI_QUEUES to
      represent i.MX6SX, it is safe for us remove FEC_QUIRK_HAS_AVB quirk
      now.
      
      FEC_QUIRK_HAS_AVB quirk is set by default in the driver, and users may
      not know much about driver details, they would waste effort to find the
      root cause, that is not we want. The following patch is a implementation
      to fix it and users don't need to modify the driver.
      Tested-by: default avatarFrieder Schrempf <frieder.schrempf@kontron.de>
      Reported-by: default avatarFrieder Schrempf <frieder.schrempf@kontron.de>
      Signed-off-by: default avatarJoakim Zhang <qiangqing.zhang@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      471ff445
    • David S. Miller's avatar
      Merge branch 'dsa-cross-chip' · 6ff5f813
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Improvement for DSA cross-chip setups
      
      This series improves some aspects in multi-switch DSA tree topologies:
      - better device tree validation
      - better handling of MTU changes
      - better handling of multicast addresses
      - removal of some unused code
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ff5f813
    • Vladimir Oltean's avatar
      net: dsa: remove cross-chip support from the MRP notifiers · f9bcdc36
      Vladimir Oltean authored
      With MRP hardware assist being supported only by the ocelot switch
      family, which by design does not support cross-chip bridging, the
      current match functions are at best a guess and have not been confirmed
      in any way to do anything relevant in a multi-switch topology.
      
      Drop the code and make the notifiers match only on the targeted switch
      port.
      
      Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9bcdc36
    • Vladimir Oltean's avatar
      net: dsa: targeted MTU notifiers should only match on one port · 88faba20
      Vladimir Oltean authored
      dsa_slave_change_mtu() calls dsa_port_mtu_change() twice:
      - it sends a cross-chip notifier with the MTU of the CPU port which is
        used to update the DSA links.
      - it sends one targeted MTU notifier which is supposed to only match the
        user port on which we are changing the MTU. The "propagate_upstream"
        variable is used here to bypass the cross-chip notifier system from
        switch.c
      
      But due to a mistake, the second, targeted notifier matches not only on
      the user port, but also on the DSA link which is a member of the same
      switch, if that exists.
      
      And because the DSA links of the entire dst were programmed in a
      previous round to the largest_mtu via a "propagate_upstream == true"
      notification, then the dsa_port_mtu_change(propagate_upstream == false)
      call that is immediately upcoming will break the MTU on the one DSA link
      which is chip-wise local to the dp whose MTU is changing right now.
      
      Example given this daisy chain topology:
      
         sw0p0     sw0p1     sw0p2     sw0p3     sw0p4
      [  cpu  ] [  user ] [  user ] [  dsa  ] [  user ]
      [   x   ] [       ] [       ] [   x   ] [       ]
                                        |
                                        +---------+
                                                  |
         sw1p0     sw1p1     sw1p2     sw1p3     sw1p4
      [  user ] [  user ] [  user ] [  dsa  ] [  dsa  ]
      [       ] [       ] [       ] [       ] [   x   ]
      
      ip link set sw0p1 mtu 9000
      ip link set sw1p1 mtu 9000 # at this stage, sw0p1 and sw1p1 can talk
                                 # to one another using jumbo frames
      ip link set sw0p2 mtu 1500 # this programs the sw0p3 DSA link first to
                                 # the largest_mtu of 9000, then reprograms it to
                                 # 1500 with the "propagate_upstream == false"
                                 # notifier, breaking communication between
                                 # sw0p1 and sw1p1
      
      To escape from this situation, make the targeted match really match on a
      single port - the user port, and rename the "propagate_upstream"
      variable to "targeted_match" to clarify the intention and avoid future
      issues.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88faba20
    • Vladimir Oltean's avatar
      net: dsa: calculate the largest_mtu across all ports in the tree · 4e4ab795
      Vladimir Oltean authored
      If we have a cross-chip topology like this:
      
         sw0p0     sw0p1     sw0p2     sw0p3     sw0p4
      [  cpu  ] [  user ] [  user ] [  dsa  ] [  user ]
                                        |
                                        +---------+
                                                  |
         sw1p0     sw1p1     sw1p2     sw1p3     sw1p4
      [  user ] [  user ] [  user ] [  dsa  ] [  dsa  ]
      
      and we issue the following commands:
      
      1. ip link set sw0p1 mtu 1700
      2. ip link set sw1p1 mtu 1600
      
      we notice the following happening:
      
      Command 1. emits a non-targeted MTU notifier for the CPU port (sw0p0)
      with the largest_mtu calculated across switch 0, of 1700. This matches
      sw0p0, sw0p3 and sw1p4 (all CPU ports and DSA links).
      Then, it emits a targeted MTU notifier for the user port (sw0p1), again
      with MTU 1700 (this doesn't matter).
      
      Command 2. emits a non-targeted MTU notifier for the CPU port (sw0p0)
      with the largest_mtu calculated across switch 1, of 1600. This matches
      the same group of ports as above, and decreases the MTU for the CPU port
      and the DSA links from 1700 to 1600.
      
      As a result, the sw0p1 user port can no longer communicate with its CPU
      port at MTU 1700.
      
      To address this, we should calculate the largest_mtu across all switches
      that may share a CPU port, and only emit MTU notifiers with that value.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e4ab795