1. 22 Jan, 2015 5 commits
  2. 21 Jan, 2015 2 commits
    • David Vrabel's avatar
      xen-netfront: use correct linear area after linearizing an skb · 02db7d0c
      David Vrabel authored
      commit 11d3d2a1 upstream.
      
      Commit 97a6d1bb (xen-netfront: Fix
      handling packets on compound pages with skb_linearize) attempted to
      fix a problem where an skb that would have required too many slots
      would be dropped causing TCP connections to stall.
      
      However, it filled in the first slot using the original buffer and not
      the new one and would use the wrong offset and grant access to the
      wrong page.
      
      Netback would notice the malformed request and stop all traffic on the
      VIF, reporting:
      
          vif vif-3-0 vif3.0: txreq.offset: 85e, size: 4002, end: 6144
          vif vif-3-0 vif3.0: fatal error; disabling device
      Reported-by: default avatarAnthony Wright <anthony@overnetdata.com>
      Tested-by: default avatarAnthony Wright <anthony@overnetdata.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      02db7d0c
    • Zoltan Kiss's avatar
      xen-netfront: Fix handling packets on compound pages with skb_linearize · de2d6357
      Zoltan Kiss authored
      commit 97a6d1bb upstream.
      
      There is a long known problem with the netfront/netback interface: if the guest
      tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
      it gets dropped. The reason is that netback maps these slots to a frag in the
      frags array, which is limited by size. Having so many slots can occur since
      compound pages were introduced, as the ring protocol slice them up into
      individual (non-compound) page aligned slots. The theoretical worst case
      scenario looks like this (note, skbs are limited to 64 Kb here):
      linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
      using 2 slots
      first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
      end and the beginning of a page, therefore they use 3 * 15 = 45 slots
      last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
      Although I don't think this 51 slots skb can really happen, we need a solution
      which can deal with every scenario. In real life there is only a few slots
      overdue, but usually it causes the TCP stream to be blocked, as the retry will
      most likely have the same buffer layout.
      This patch solves this problem by linearizing the packet. This is not the
      fastest way, and it can fail much easier as it tries to allocate a big linear
      area for the whole packet, but probably easier by an order of magnitude than
      anything else. Probably this code path is not touched very frequently anyway.
      Signed-off-by: default avatarZoltan Kiss <zoltan.kiss@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <Ian.Campbell@citrix.com>
      Cc: Paul Durrant <paul.durrant@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>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      de2d6357
  3. 20 Jan, 2015 1 commit
  4. 19 Jan, 2015 15 commits
  5. 16 Jan, 2015 17 commits