1. 23 Jul, 2018 37 commits
  2. 22 Jul, 2018 3 commits
    • Jakub Kicinski's avatar
      nfp: avoid buffer leak when FW communication fails · 07300f77
      Jakub Kicinski authored
      After device is stopped we reset the rings by moving all free buffers
      to positions [0, cnt - 2], and clear the position cnt - 1 in the ring.
      We then proceed to clear the read/write pointers.  This means that if
      we try to reset the ring again the code will assume that the next to
      fill buffer is at position 0 and swap it with cnt - 1.  Since we
      previously cleared position cnt - 1 it will lead to leaking the first
      buffer and leaving ring in a bad state.
      
      This scenario can only happen if FW communication fails, in which case
      the ring will never be used again, so the fact it's in a bad state will
      not be noticed.  Buffer leak is the only problem.  Don't try to move
      buffers in the ring if the read/write pointers indicate the ring was
      never used or have already been reset.
      
      nfp_net_clear_config_and_disable() is now fully idempotent.
      
      Found by code inspection, FW communication failures are very rare,
      and reconfiguring a live device is not common either, so it's unlikely
      anyone has ever noticed the leak.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07300f77
    • Jakub Kicinski's avatar
      nfp: bring back support for offloading shared blocks · 042f8825
      Jakub Kicinski authored
      Now that we have offload replay infrastructure added by
      commit 32636742 ("net: sched: call reoffload op on block callback reg")
      and flows are guaranteed to be removed correctly, we can revert
      commit 951a8ee6 ("nfp: reject binding to shared blocks").
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarJohn Hurley <john.hurley@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      042f8825
    • Vitaly Kuznetsov's avatar
      xen-netfront: fix queue name setting · 2d408c0d
      Vitaly Kuznetsov authored
      Commit f599c64f ("xen-netfront: Fix race between device setup and
      open") changed the initialization order: xennet_create_queues() now
      happens before we do register_netdev() so using netdev->name in
      xennet_init_queue() is incorrect, we end up with the following in
      /proc/interrupts:
      
       60:        139          0   xen-dyn    -event     eth%d-q0-tx
       61:        265          0   xen-dyn    -event     eth%d-q0-rx
       62:        234          0   xen-dyn    -event     eth%d-q1-tx
       63:          1          0   xen-dyn    -event     eth%d-q1-rx
      
      and this looks ugly. Actually, using early netdev name (even when it's
      already set) is also not ideal: nowadays we tend to rename eth devices
      and queue name may end up not corresponding to the netdev name.
      
      Use nodename from xenbus device for queue naming: this can't change in VM's
      lifetime. Now /proc/interrupts looks like
      
       62:        202          0   xen-dyn    -event     device/vif/0-q0-tx
       63:        317          0   xen-dyn    -event     device/vif/0-q0-rx
       64:        262          0   xen-dyn    -event     device/vif/0-q1-tx
       65:         17          0   xen-dyn    -event     device/vif/0-q1-rx
      
      Fixes: f599c64f ("xen-netfront: Fix race between device setup and open")
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d408c0d