1. 18 Jan, 2017 1 commit
  2. 10 Nov, 2016 2 commits
  3. 07 Nov, 2016 1 commit
  4. 13 Oct, 2016 1 commit
  5. 07 Oct, 2016 1 commit
  6. 23 Sep, 2016 1 commit
  7. 17 Sep, 2016 1 commit
    • Filipe Manco's avatar
      xen-netback: fix error handling on netback_probe() · cce94483
      Filipe Manco authored
      
      
      In case of error during netback_probe() (e.g. an entry missing on the
      xenstore) netback_remove() is called on the new device, which will set
      the device backend state to XenbusStateClosed by calling
      set_backend_state(). However, the backend state wasn't initialized by
      netback_probe() at this point, which will cause and invalid transaction
      and set_backend_state() to BUG().
      
      Initialize the backend state at the beginning of netback_probe() to
      XenbusStateInitialising, and create two new valid state transitions on
      set_backend_state(), from XenbusStateInitialising to XenbusStateClosed,
      and from XenbusStateInitialising to XenbusStateInitWait.
      Signed-off-by: default avatarFilipe Manco <filipe.manco@neclab.eu>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cce94483
  8. 19 Aug, 2016 1 commit
  9. 16 May, 2016 1 commit
  10. 14 Mar, 2016 1 commit
  11. 07 Feb, 2016 1 commit
  12. 19 Oct, 2015 1 commit
  13. 02 Sep, 2015 1 commit
    • Paul Durrant's avatar
      xen-netback: add support for multicast control · 210c34dc
      Paul Durrant authored
      Xen's PV network protocol includes messages to add/remove ethernet
      multicast addresses to/from a filter list in the backend. This allows
      the frontend to request the backend only forward multicast packets
      which are of interest thus preventing unnecessary noise on the shared
      ring.
      
      The canonical netif header in git://xenbits.xen.org/xen.git
      
       specifies
      the message format (two more XEN_NETIF_EXTRA_TYPEs) so the minimal
      necessary changes have been pulled into include/xen/interface/io/netif.h.
      
      To prevent the frontend from extending the multicast filter list
      arbitrarily a limit (XEN_NETBK_MCAST_MAX) has been set to 64 entries.
      This limit is not specified by the protocol and so may change in future.
      If the limit is reached then the next XEN_NETIF_EXTRA_TYPE_MCAST_ADD
      sent by the frontend will be failed with NETIF_RSP_ERROR.
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      210c34dc
  14. 23 Jun, 2015 1 commit
    • Palik, Imre's avatar
      xen-netback: fix a BUG() during initialization · 12b322ac
      Palik, Imre authored
      Commit edafc132
      
       ("xen-netback: making the bandwidth limiter runtime settable")
      introduced the capability to change the bandwidth rate limit at runtime.
      But it also introduced a possible crashing bug.
      
      If netback receives two XenbusStateConnected without getting the
      hotplug-status watch firing in between, then it will try to register the
      watches for the rate limiter again.  But this triggers a BUG() in the watch
      registration code.
      
      The fix modifies connect() to remove the possibly existing packet-rate
      watches before trying to install those watches.  This behaviour is in line
      with how connect() deals with the hotplug-status watch.
      Signed-off-by: default avatarImre Palik <imrep@amazon.de>
      Cc: Matt Wilson <msw@amazon.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12b322ac
  15. 01 Jun, 2015 1 commit
    • Ian Campbell's avatar
      xen: netback: read hotplug script once at start of day. · 31a41898
      Ian Campbell authored
      
      
      When we come to tear things down in netback_remove() and generate the
      uevent it is possible that the xenstore directory has already been
      removed (details below).
      
      In such cases netback_uevent() won't be able to read the hotplug
      script and will write a xenstore error node.
      
      A recent change to the hypervisor exposed this race such that we now
      sometimes lose it (where apparently we didn't ever before).
      
      Instead read the hotplug script configuration during setup and use it
      for the lifetime of the backend device.
      
      The apparently more obvious fix of moving the transition to
      state=Closed in netback_remove() to after the uevent does not work
      because it is possible that we are already in state=Closed (in
      reaction to the guest having disconnected as it shutdown). Being
      already in Closed means the toolstack is at liberty to start tearing
      down the xenstore directories. In principal it might be possible to
      arrange to unregister the device sooner (e.g on transition to Closing)
      such that xenstore would still be there but this state machine is
      fragile and prone to anger...
      
      A modern Xen system only relies on the hotplug uevent for driver
      domains, when the backend is in the same domain as the toolstack it
      will run the necessary setup/teardown directly in the correct sequence
      wrt xenstore changes.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31a41898
  16. 27 May, 2015 1 commit
  17. 20 Mar, 2015 1 commit
  18. 06 Jan, 2015 1 commit
  19. 18 Dec, 2014 1 commit
  20. 09 Dec, 2014 1 commit
  21. 24 Nov, 2014 1 commit
  22. 25 Oct, 2014 3 commits
    • David Vrabel's avatar
      xen-netback: reintroduce guest Rx stall detection · ecf08d2d
      David Vrabel authored
      
      
      If a frontend not receiving packets it is useful to detect this and
      turn off the carrier so packets are dropped early instead of being
      queued and drained when they expire.
      
      A to-guest queue is stalled if it doesn't have enough free slots for a
      an extended period of time (default 60 s).
      
      If at least one queue is stalled, the carrier is turned off (in the
      expectation that the other queues will soon stall as well).  The
      carrier is only turned on once all queues are ready.
      
      When the frontend connects, all the queues start in the stalled state
      and only become ready once the frontend queues enough Rx requests.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ecf08d2d
    • David Vrabel's avatar
      xen-netback: fix unlimited guest Rx internal queue and carrier flapping · f48da8b1
      David Vrabel authored
      
      
      Netback needs to discard old to-guest skb's (guest Rx queue drain) and
      it needs detect guest Rx stalls (to disable the carrier so packets are
      discarded earlier), but the current implementation is very broken.
      
      1. The check in hard_start_xmit of the slot availability did not
         consider the number of packets that were already in the guest Rx
         queue.  This could allow the queue to grow without bound.
      
         The guest stops consuming packets and the ring was allowed to fill
         leaving S slot free.  Netback queues a packet requiring more than S
         slots (ensuring that the ring stays with S slots free).  Netback
         queue indefinately packets provided that then require S or fewer
         slots.
      
      2. The Rx stall detection is not triggered in this case since the
         (host) Tx queue is not stopped.
      
      3. If the Tx queue is stopped and a guest Rx interrupt occurs, netback
         will consider this an Rx purge event which may result in it taking
         the carrier down unnecessarily.  It also considers a queue with
         only 1 slot free as unstalled (even though the next packet might
         not fit in this).
      
      The internal guest Rx queue is limited by a byte length (to 512 Kib,
      enough for half the ring).  The (host) Tx queue is stopped and started
      based on this limit.  This sets an upper bound on the amount of memory
      used by packets on the internal queue.
      
      This allows the estimatation of the number of slots for an skb to be
      removed (it wasn't a very good estimate anyway).  Instead, the guest
      Rx thread just waits for enough free slots for a maximum sized packet.
      
      skbs queued on the internal queue have an 'expires' time (set to the
      current time plus the drain timeout).  The guest Rx thread will detect
      when the skb at the head of the queue has expired and discard expired
      skbs.  This sets a clear upper bound on the length of time an skb can
      be queued for.  For a guest being destroyed the maximum time needed to
      wait for all the packets it sent to be dropped is still the drain
      timeout (10 s) since it will not be sending new packets.
      
      Rx stall detection is reintroduced in a later commit.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f48da8b1
    • David Vrabel's avatar
      xen-netback: make feature-rx-notify mandatory · bc96f648
      David Vrabel authored
      
      
      Frontends that do not provide feature-rx-notify may stall because
      netback depends on the notification from frontend to wake the guest Rx
      thread (even if can_queue is false).
      
      This could be fixed but feature-rx-notify was introduced in 2006 and I
      am not aware of any frontends that do not implement this.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc96f648
  23. 06 Oct, 2014 1 commit
  24. 14 Aug, 2014 2 commits
  25. 09 Jul, 2014 1 commit
    • Zoltan Kiss's avatar
      xen-netback: Adding debugfs "io_ring_qX" files · f51de243
      Zoltan Kiss authored
      
      
      This patch adds debugfs capabilities to netback. There used to be a similar
      patch floating around for classic kernel, but it used procfs. It is based on a
      very similar blkback patch.
      It creates xen-netback/[vifname]/io_ring_q[queueno] files, reading them output
      various ring variables etc. Writing "kick" into it imitates an interrupt
      happened, it can be useful to check whether the ring is just stalled due to a
      missed interrupt.
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f51de243
  26. 25 Jun, 2014 1 commit
    • Wei Liu's avatar
      xen-netback: bookkeep number of active queues in our own module · f7b50c4e
      Wei Liu authored
      
      
      The original code uses netdev->real_num_tx_queues to bookkeep number of
      queues and invokes netif_set_real_num_tx_queues to set the number of
      queues. However, netif_set_real_num_tx_queues doesn't allow
      real_num_tx_queues to be smaller than 1, which means setting the number
      to 0 will not work and real_num_tx_queues is untouched.
      
      This is bogus when xenvif_free is invoked before any number of queues is
      allocated. That function needs to iterate through all queues to free
      resources. Using the wrong number of queues results in NULL pointer
      dereference.
      
      So we bookkeep the number of queues in xen-netback to solve this
      problem. This fixes a regression introduced by multiqueue patchset in
      3.16-rc1.
      
      There's another bug in original code that the real number of RX queues
      is never set. In current Xen multiqueue design, the number of TX queues
      and RX queues are in fact the same. We need to set the numbers of TX and
      RX queues to the same value.
      
      Also remove xenvif_select_queue and leave queue selection to core
      driver, as suggested by David Miller.
      Reported-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarWei Liu <wei.liu2@citrix.com>
      CC: Ian Campbell <ian.campbell@citrix.com>
      CC: Paul Durrant <paul.durrant@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7b50c4e
  27. 04 Jun, 2014 2 commits
  28. 06 Dec, 2013 1 commit
    • Jeff Kirsher's avatar
      drivers/net/*: Fix FSF address in file headers · adf8d3ff
      Jeff Kirsher authored
      Several files refer to an old address for the Free Software Foundation
      in the file header comment.  Resolve by replacing the address with
      the URL <http://www.gnu.org/licenses/
      
      > so that we do not have to keep
      updating the header comments anytime the address changes.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Veaceslav Falico <vfalico@redhat.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Haiyang Zhang <haiyangz@microsoft.com>
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      CC: Paul Mackerras <paulus@samba.org>
      CC: Ian Campbell <ian.campbell@citrix.com>
      CC: Wei Liu <wei.liu2@citrix.com>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      CC: "Michael S. Tsirkin" <mst@redhat.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adf8d3ff
  29. 17 Oct, 2013 4 commits
  30. 08 Oct, 2013 1 commit
  31. 30 Sep, 2013 1 commit
  32. 19 Sep, 2013 1 commit
    • Paul Durrant's avatar
      xen-netback: Don't destroy the netdev until the vif is shut down · 279f438e
      Paul Durrant authored
      
      
      Without this patch, if a frontend cycles through states Closing
      and Closed (which Windows frontends need to do) then the netdev
      will be destroyed and requires re-invocation of hotplug scripts
      to restore state before the frontend can move to Connected. Thus
      when udev is not in use the backend gets stuck in InitWait.
      
      With this patch, the netdev is left alone whilst the backend is
      still online and is only de-registered and freed just prior to
      destroying the vif (which is also nicely symmetrical with the
      netdev allocation and registration being done during probe) so
      no re-invocation of hotplug scripts is required.
      Signed-off-by: default avatarPaul Durrant <paul.durrant@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      279f438e