1. 03 2月, 2015 1 次提交
  2. 28 1月, 2015 2 次提交
  3. 24 1月, 2015 1 次提交
  4. 19 12月, 2014 1 次提交
  5. 07 11月, 2014 1 次提交
  6. 30 10月, 2014 1 次提交
  7. 26 10月, 2014 2 次提交
    • D
      xen-netback: reintroduce guest Rx stall detection · ecf08d2d
      David Vrabel 提交于
      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: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecf08d2d
    • D
      xen-netback: fix unlimited guest Rx internal queue and carrier flapping · f48da8b1
      David Vrabel 提交于
      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: NDavid Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f48da8b1
  8. 14 8月, 2014 1 次提交
  9. 08 8月, 2014 1 次提交
  10. 06 8月, 2014 2 次提交
    • Z
      xen-netback: Turn off the carrier if the guest is not able to receive · f34a4cf9
      Zoltan Kiss 提交于
      Currently when the guest is not able to receive more packets, qdisc layer starts
      a timer, and when it goes off, qdisc is started again to deliver a packet again.
      This is a very slow way to drain the queues, consumes unnecessary resources and
      slows down other guests shutdown.
      This patch change the behaviour by turning the carrier off when that timer
      fires, so all the packets are freed up which were stucked waiting for that vif.
      Instead of the rx_queue_purge bool it uses the VIF_STATUS_RX_PURGE_EVENT bit to
      signal the thread that either the timeout happened or an RX interrupt arrived,
      so the thread can check what it should do. It also disables NAPI, so the guest
      can't transmit, but leaves the interrupts on, so it can resurrect.
      Only the queues which brought down the interface can enable it again, the bit
      QUEUE_STATUS_RX_STALLED makes sure of that.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f34a4cf9
    • Z
      xen-netback: Using a new state bit instead of carrier · 3d1af1df
      Zoltan Kiss 提交于
      This patch introduces a new state bit VIF_STATUS_CONNECTED to track whether the
      vif is in a connected state. Using carrier will not work with the next patch
      in this series, which aims to turn the carrier temporarily off if the guest
      doesn't seem to be able to receive packets.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      
      v2:
      - rename the bitshift type to "enum state_bit_shift" here, not in the next patch
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d1af1df
  11. 21 7月, 2014 4 次提交
  12. 09 7月, 2014 1 次提交
    • Z
      xen-netback: Adding debugfs "io_ring_qX" files · f51de243
      Zoltan Kiss 提交于
      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: NZoltan 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: NDavid S. Miller <davem@davemloft.net>
      f51de243
  13. 06 6月, 2014 1 次提交
    • Z
      xen-netback: Fix handling of skbs requiring too many slots · 59ae9fc6
      Zoltan Kiss 提交于
      A recent commit (a02eb4 "xen-netback: worse-case estimate in xenvif_rx_action is
      underestimating") capped the slot estimation to MAX_SKB_FRAGS, but that triggers
      the next BUG_ON a few lines down, as the packet consumes more slots than
      estimated.
      This patch introduces full_coalesce on the skb callback buffer, which is used in
      start_new_rx_buffer() to decide whether netback needs coalescing more
      aggresively. By doing that, no packet should need more than
      (XEN_NETIF_MAX_TX_SIZE + 1) / PAGE_SIZE data slots (excluding the optional GSO
      slot, it doesn't carry data, therefore irrelevant in this case), as the provided
      buffers are fully utilized.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Cc: Paul Durrant <paul.durrant@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Reviewed-by: NPaul Durrant <paul.durrant@gmail.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae9fc6
  14. 05 6月, 2014 2 次提交
  15. 17 5月, 2014 1 次提交
  16. 16 5月, 2014 1 次提交
    • Z
      xen-netback: Fix grant ref resolution in RX path · 58375744
      Zoltan Kiss 提交于
      The original series for reintroducing grant mapping for netback had a patch [1]
      to handle receiving of packets from an another VIF. Grant copy on the receiving
      side needs the grant ref of the page to set up the op.
      The original patch assumed (wrongly) that the frags array haven't changed. In
      the case reported by Sander, the sending guest sent a packet where the linear
      buffer and the first frag were under PKT_PROT_LEN (=128) bytes.
      xenvif_tx_submit() then pulled up the linear area to 128 bytes, and ditched the
      first frag. The receiving side had an off-by-one problem when gathered the grant
      refs.
      This patch fixes that by checking whether the actual frag's page pointer is the
      same as the page in the original frag list. It can handle any kind of changes on
      the original frags array, like:
      - removing granted frags from the array at any point
      - adding local pages to the frags list anywhere
      - reordering the frags
      It's optimized to the most common case, when there is 1:1 relation between the
      frags and the list, plus works optimal when frags are removed from the end or
      the beginning.
      
      [1]: 3e2234: xen-netback: Handle foreign mapped pages on the guest RX path
      Reported-by: NSander Eikelenboom <linux@eikelenboom.it>
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      58375744
  17. 04 4月, 2014 3 次提交
  18. 02 4月, 2014 1 次提交
    • W
      xen-netback: disable rogue vif in kthread context · e9d8b2c2
      Wei Liu 提交于
      When netback discovers frontend is sending malformed packet it will
      disables the interface which serves that frontend.
      
      However disabling a network interface involving taking a mutex which
      cannot be done in softirq context, so we need to defer this process to
      kthread context.
      
      This patch does the following:
      1. introduce a flag to indicate the interface is disabled.
      2. check that flag in TX path, don't do any work if it's true.
      3. check that flag in RX path, turn off that interface if it's true.
      
      The reason to disable it in RX path is because RX uses kthread. After
      this change the behavior of netback is still consistent -- it won't do
      any TX work for a rogue frontend, and the interface will be eventually
      turned off.
      
      Also change a "continue" to "break" after xenvif_fatal_tx_err, as it
      doesn't make sense to continue processing packets if frontend is rogue.
      
      This is a fix for XSA-90.
      Reported-by: NTörök Edwin <edwin@etorok.net>
      Signed-off-by: NWei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9d8b2c2
  19. 30 3月, 2014 3 次提交
  20. 27 3月, 2014 3 次提交
  21. 26 3月, 2014 2 次提交
  22. 11 3月, 2014 1 次提交
  23. 08 3月, 2014 4 次提交
    • Z
      xen-netback: Aggregate TX unmap operations · e9275f5e
      Zoltan Kiss 提交于
      Unmapping causes TLB flushing, therefore we should make it in the largest
      possible batches. However we shouldn't starve the guest for too long. So if
      the guest has space for at least two big packets and we don't have at least a
      quarter ring to unmap, delay it for at most 1 milisec.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9275f5e
    • Z
      xen-netback: Timeout packets in RX path · 09350788
      Zoltan Kiss 提交于
      A malicious or buggy guest can leave its queue filled indefinitely, in which
      case qdisc start to queue packets for that VIF. If those packets came from an
      another guest, it can block its slots and prevent shutdown. To avoid that, we
      make sure the queue is drained in every 10 seconds.
      The QDisc queue in worst case takes 3 round to flush usually.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09350788
    • Z
      xen-netback: Handle guests with too many frags · e3377f36
      Zoltan Kiss 提交于
      Xen network protocol had implicit dependency on MAX_SKB_FRAGS. Netback has to
      handle guests sending up to XEN_NETBK_LEGACY_SLOTS_MAX slots. To achieve that:
      - create a new skb
      - map the leftover slots to its frags (no linear buffer here!)
      - chain it to the previous through skb_shinfo(skb)->frag_list
      - map them
      - copy and coalesce the frags into a brand new one and send it to the stack
      - unmap the 2 old skb's pages
      
      It's also introduces new stat counters, which help determine how often the guest
      sends a packet with more than MAX_SKB_FRAGS frags.
      
      NOTE: if bisect brought you here, you should apply the series up until
      "xen-netback: Timeout packets in RX path", otherwise malicious guests can block
      other guests by not releasing their sent packets.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3377f36
    • Z
      xen-netback: Add stat counters for zerocopy · 1bb332af
      Zoltan Kiss 提交于
      These counters help determine how often the buffers had to be copied. Also
      they help find out if packets are leaked, as if "sent != success + fail",
      there are probably packets never freed up properly.
      
      NOTE: if bisect brought you here, you should apply the series up until
      "xen-netback: Timeout packets in RX path", otherwise Windows guests can't work
      properly and malicious guests can block other guests by not releasing their sent
      packets.
      Signed-off-by: NZoltan Kiss <zoltan.kiss@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bb332af