1. 17 Jun, 2019 12 commits
    • Mitch Williams's avatar
      iavf: wait longer for close to complete · 88ec7308
      Mitch Williams authored
      On some hardware/driver/architecture combinations, it may take longer
      than 200msec for all close operations to be completed, causing a
      spurious error message to be logged.
      
      Increase the timeout value to 500msec to avoid this erroneous error.
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      88ec7308
    • Mitch Williams's avatar
      iavf: use signed variable · 168d91cf
      Mitch Williams authored
      The counter variable in iavf_clean_tx_irq starts out negative and climbs
      to 0. So allocating it as u16 is actually a really bad idea that just
      happens to work because the value underflows and overflows consistently
      on most architectures.
      
      Replace the u16 with an int so signed math works as expected.
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      168d91cf
    • Akeem G Abodunrin's avatar
      iavf: Create VLAN tag elements starting from the first element · c2417a7b
      Akeem G Abodunrin authored
      This patch changes how VLAN tag are being populated and programmed into
      the HW - Instead of start adding VF VLAN tag from the last member of the
      element list, start from the first member of the list, until number of
      allowed VLAN tags is exhausted in the HW.
      Signed-off-by: default avatarAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c2417a7b
    • Jiri Pirko's avatar
      net: sched: cls_matchall: allow to delete filter · f517f271
      Jiri Pirko authored
      Currently user is unable to delete the filter. See following example:
      $ tc filter add dev ens16np1 ingress pref 1 handle 1 matchall action drop
      $ tc filter show dev ens16np1 ingress
      filter protocol all pref 1 matchall chain 0
      filter protocol all pref 1 matchall chain 0 handle 0x1
        in_hw
              action order 1: gact action drop
               random type none pass val 0
               index 1 ref 1 bind 1
      
      $ tc filter del dev ens16np1 ingress pref 1 handle 1 matchall action drop
      RTNETLINK answers: Operation not supported
      
      Implement tcf_proto_ops->delete() op and allow user to delete the filter.
      Reported-by: default avatarEli Cohen <eli@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f517f271
    • Colin Ian King's avatar
      net: hns3: fix dereference of ae_dev before it is null checked · ad9bf545
      Colin Ian King authored
      Pointer ae_dev is null checked however, prior to that it is dereferenced
      when assigned pointer ops. Fix this by assigning pointer ops after ae_dev
      has been null checked.
      
      Addresses-Coverity: ("Dereference before null check")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad9bf545
    • David S. Miller's avatar
      Merge branch 'net-sched-act_ctinfo-fixes' · 43321251
      David S. Miller authored
      Kevin Darbyshire-Bryant says:
      
      ====================
      net: sched: act_ctinfo: fixes
      
      This is first attempt at sending a small series.  Order is important
      because one bug (policy validation) prevents us from encountering the
      more important 'OOPS' generating bug in action creation.  Fix the OOPS
      first.
      
      Confession time: Until very recently, development of this module has
      been done on 'net-next' tree to 'clean compile' level with run-time
      testing on backports to 4.14 & 4.19 kernels under openwrt.  It turns out
      that sched: action: based code has been under more active change than I
      realised.
      
      During the back & forward porting during development & testing, the
      critical ACT_P_CREATED return code got missed despite being in the 4.14
      & 4.19 backports.  I have now gone through the init functions, using
      act_csum as reference with a fine toothed comb and am happy they do the
      same things.
      
      This issue hadn't been caught till now due to another issue caused by
      new strict nla_parse_nested function failing parsing validation before
      action creation.
      
      Thanks to Marcelo Leitner <marcelo.leitner@gmail.com> for flagging
      extack deficiency (fixed in 733f0766 sched: act_ctinfo: use extack
      error reporting) which led to b424e432 ("netlink: add validation of
      NLA_F_NESTED flag") and 8cb08174 ("netlink: make validation more
      configurable for future strictness”) which led to the policy validation
      fix, which then led to the action creation fix both contained in this
      series.
      
      If I ever get to a developer conference please feel free to
      tar/feather/apply cone of shame.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43321251
    • Kevin Darbyshire-Bryant's avatar
      net: sched: act_ctinfo: fix policy validation · c197d636
      Kevin Darbyshire-Bryant authored
      Fix nla_policy definition by specifying an exact length type attribute
      to CTINFO action paraneter block structure.  Without this change,
      netlink parsing will fail validation and the action will not be
      instantiated.
      
      8cb08174 ("netlink: make validation more configurable for future")
      introduced much stricter checking to attributes being passed via
      netlink.  Existing actions were updated to use less restrictive
      deprecated versions of nla_parse_nested.
      
      As a new module, act_ctinfo should be designed to use the strict
      checking model otherwise, well, what was the point of implementing it.
      
      Confession time: Until very recently, development of this module has
      been done on 'net-next' tree to 'clean compile' level with run-time
      testing on backports to 4.14 & 4.19 kernels under openwrt.  This is how
      I managed to miss the run-time impacts of the new strict
      nla_parse_nested function.  I hopefully have learned something from this
      (glances toward laptop running a net-next kernel)
      
      There is however a still outstanding implication on iproute2 user space
      in that it needs to be told to pass nested netlink messages with the
      nested attribute actually set.  So even with this kernel fix to do
      things correctly you still cannot instantiate a new 'strict'
      nla_parse_nested based action such as act_ctinfo with iproute2's tc.
      Signed-off-by: default avatarKevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c197d636
    • Kevin Darbyshire-Bryant's avatar
      net: sched: act_ctinfo: fix action creation · a658c2e4
      Kevin Darbyshire-Bryant authored
      Use correct return value on action creation: ACT_P_CREATED.
      
      The use of incorrect return value could result in a situation where the
      system thought a ctinfo module was listening but actually wasn't
      instantiated correctly leading to an OOPS in tcf_generic_walker().
      
      Confession time: Until very recently, development of this module has
      been done on 'net-next' tree to 'clean compile' level with run-time
      testing on backports to 4.14 & 4.19 kernels under openwrt.  During the
      back & forward porting during development & testing, the critical
      ACT_P_CREATED return code got missed despite being in the 4.14 & 4.19
      backports.  I have now gone through the init functions, using act_csum
      as reference with a fine toothed comb.  Bonus, no more OOPSes.  I
      managed to also miss this issue till now due to the new strict
      nla_parse_nested function failing validation before action creation.
      
      As an inexperienced developer I've learned that
      copy/pasting/backporting/forward porting code correctly is hard.  If I
      ever get to a developer conference I shall don the cone of shame.
      Signed-off-by: default avatarKevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a658c2e4
    • Jason Wang's avatar
      vhost_net: disable zerocopy by default · 098eadce
      Jason Wang authored
      Vhost_net was known to suffer from HOL[1] issues which is not easy to
      fix. Several downstream disable the feature by default. What's more,
      the datapath was split and datacopy path got the support of batching
      and XDP support recently which makes it faster than zerocopy part for
      small packets transmission.
      
      It looks to me that disable zerocopy by default is more
      appropriate. It cold be enabled by default again in the future if we
      fix the above issues.
      
      [1] https://patchwork.kernel.org/patch/3787671/Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      098eadce
    • Ard Biesheuvel's avatar
      net: ipv4: move tcp_fastopen server side code to SipHash library · c681edae
      Ard Biesheuvel authored
      Using a bare block cipher in non-crypto code is almost always a bad idea,
      not only for security reasons (and we've seen some examples of this in
      the kernel in the past), but also for performance reasons.
      
      In the TCP fastopen case, we call into the bare AES block cipher one or
      two times (depending on whether the connection is IPv4 or IPv6). On most
      systems, this results in a call chain such as
      
        crypto_cipher_encrypt_one(ctx, dst, src)
          crypto_cipher_crt(tfm)->cit_encrypt_one(crypto_cipher_tfm(tfm), ...);
            aesni_encrypt
              kernel_fpu_begin();
              aesni_enc(ctx, dst, src); // asm routine
              kernel_fpu_end();
      
      It is highly unlikely that the use of special AES instructions has a
      benefit in this case, especially since we are doing the above twice
      for IPv6 connections, instead of using a transform which can process
      the entire input in one go.
      
      We could switch to the cbcmac(aes) shash, which would at least get
      rid of the duplicated overhead in *some* cases (i.e., today, only
      arm64 has an accelerated implementation of cbcmac(aes), while x86 will
      end up using the generic cbcmac template wrapping the AES-NI cipher,
      which basically ends up doing exactly the above). However, in the given
      context, it makes more sense to use a light-weight MAC algorithm that
      is more suitable for the purpose at hand, such as SipHash.
      
      Since the output size of SipHash already matches our chosen value for
      TCP_FASTOPEN_COOKIE_SIZE, and given that it accepts arbitrary input
      sizes, this greatly simplifies the code as well.
      
      NOTE: Server farms backing a single server IP for load balancing purposes
            and sharing a single fastopen key will be adversely affected by
            this change unless all systems in the pool receive their kernel
            upgrades at the same time.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c681edae
    • Tuong Lien's avatar
      tipc: include retrans failure detection for unicast · 6a6b5c8b
      Tuong Lien authored
      In patch series, commit 9195948f ("tipc: improve TIPC throughput by
      Gap ACK blocks"), as for simplicity, the repeated retransmit failures'
      detection in the function - "tipc_link_retrans()" was kept there for
      broadcast retransmissions only.
      
      This commit now reapplies this feature for link unicast retransmissions
      that has been done via the function - "tipc_link_advance_transmq()".
      
      Also, the "tipc_link_retrans()" is renamed to "tipc_link_bc_retrans()"
      as it is used only for broadcast.
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.se>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a6b5c8b
    • Hangbin Liu's avatar
      team: add ethtool get_link_ksettings · 9ed68ca0
      Hangbin Liu authored
      Like bond, add ethtool get_link_ksettings to show the total speed.
      
      v2: no update, just repost.
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ed68ca0
  2. 16 Jun, 2019 12 commits
  3. 15 Jun, 2019 16 commits