1. 25 7月, 2013 15 次提交
  2. 24 7月, 2013 5 次提交
  3. 23 7月, 2013 7 次提交
  4. 20 7月, 2013 1 次提交
  5. 19 7月, 2013 2 次提交
    • J
      macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS · ece793fc
      Jason Wang 提交于
      We try to linearize part of the skb when the number of iov is greater than
      MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
      one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
      network.
      
      Solve this problem by calculate the pages needed for iov before trying to do
      zerocopy and switch to use copy instead of zerocopy if it needs more than
      MAX_SKB_FRAGS.
      
      This is done through introducing a new helper to count the pages for iov, and
      call uarg->callback() manually when switching from zerocopy to copy to notify
      vhost.
      
      We can do further optimization on top.
      
      This bug were introduced from b92946e2
      (macvtap: zerocopy: validate vectors before building skb).
      
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ece793fc
    • J
      tuntap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS · 88529176
      Jason Wang 提交于
      We try to linearize part of the skb when the number of iov is greater than
      MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than
      one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest
      network.
      
      Solve this problem by calculate the pages needed for iov before trying to do
      zerocopy and switch to use copy instead of zerocopy if it needs more than
      MAX_SKB_FRAGS.
      
      This is done through introducing a new helper to count the pages for iov, and
      call uarg->callback() manually when switching from zerocopy to copy to notify
      vhost.
      
      We can do further optimization on top.
      
      The bug were introduced from commit 0690899b
      (tun: experimental zero copy tx support)
      
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88529176
  6. 18 7月, 2013 2 次提交
    • J
      xen-netfront: pull on receive skb may need to happen earlier · 093b9c71
      Jan Beulich 提交于
      Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
      linear area is big enough on RX") xennet_fill_frags() may end up
      filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce
      the fragment count subsequently via __pskb_pull_tail(). That's a
      result of xennet_get_responses() allowing a maximum of one more slot to
      be consumed (and intermediately transformed into a fragment) if the
      head slot has a size less than or equal to RX_COPY_THRESHOLD.
      
      Hence we need to adjust xennet_fill_frags() to pull earlier if we
      reached the maximum fragment count - due to the described behavior of
      xennet_get_responses() this guarantees that at least the first fragment
      will get completely consumed, and hence the fragment count reduced.
      
      In order to not needlessly call __pskb_pull_tail() twice, make the
      original call conditional upon the pull target not having been reached
      yet, and defer the newly added one as much as possible (an alternative
      would have been to always call the function right before the call to
      xennet_fill_frags(), but that would imply more frequent cases of
      needing to call it twice).
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Acked-by: NWei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: stable@vger.kernel.org (3.6 onwards)
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      093b9c71
    • S
      vxlan: add necessary locking on device removal · fe5c3561
      stephen hemminger 提交于
      The socket management is now done in workqueue (outside of RTNL)
      and protected by vn->sock_lock. There were two possible bugs, first
      the vxlan device was removed from the VNI hash table per socket without
      holding lock. And there was a race when device is created and the workqueue
      could run after deletion.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe5c3561
  7. 17 7月, 2013 7 次提交
  8. 13 7月, 2013 1 次提交
    • N
      via-rhine: fix dma mapping errors · 9b4fe5fb
      Neil Horman 提交于
      this bug:
      https://bugzilla.redhat.com/show_bug.cgi?id=951695
      
      Reported a dma debug backtrace:
      
      WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
      Hardware name: To Be Filled By O.E.M.
      via-rhine 0000:00:12.0: DMA-API: device driver failed to check map error[device
      address=0x0000000075a837b2] [size=90 bytes] [mapped as single]
      Modules linked in: ip6_tables gspca_spca561 gspca_main videodev media
      snd_hda_codec_realtek snd_hda_intel i2c_viapro snd_hda_codec snd_hwdep snd_seq
      ppdev mperf via_rhine coretemp snd_pcm mii microcode snd_page_alloc snd_timer
      snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc
      parport shpchp ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper ttm drm
      pata_via sata_via i2c_core uinput
      Pid: 295, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.1.fc20.x86_64 #1
      Call Trace:
       <IRQ>  [<ffffffff81068dd0>] warn_slowpath_common+0x70/0xa0
       [<ffffffff81068e4c>] warn_slowpath_fmt+0x4c/0x50
       [<ffffffff8137ec6d>] check_unmap+0x47d/0x930
       [<ffffffff810ace9f>] ? local_clock+0x5f/0x70
       [<ffffffff8137f17f>] debug_dma_unmap_page+0x5f/0x70
       [<ffffffffa0225edc>] ? rhine_ack_events.isra.14+0x3c/0x50 [via_rhine]
       [<ffffffffa02275f8>] rhine_napipoll+0x1d8/0xd80 [via_rhine]
       [<ffffffff815d3d51>] ? net_rx_action+0xa1/0x380
       [<ffffffff815d3e22>] net_rx_action+0x172/0x380
       [<ffffffff8107345f>] __do_softirq+0xff/0x400
       [<ffffffff81073925>] irq_exit+0xb5/0xc0
       [<ffffffff81724cd6>] do_IRQ+0x56/0xc0
       [<ffffffff81719ff2>] common_interrupt+0x72/0x72
       <EOI>  [<ffffffff8170ff57>] ? __slab_alloc+0x4c2/0x526
       [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
       [<ffffffff810d5807>] ? __lock_is_held+0x57/0x80
       [<ffffffff811992e0>] ? mmap_region+0x2b0/0x5a0
       [<ffffffff811bf1bf>] kmem_cache_alloc+0x2df/0x360
       [<ffffffff811992e0>] mmap_region+0x2b0/0x5a0
       [<ffffffff811998e6>] do_mmap_pgoff+0x316/0x3d0
       [<ffffffff81183ca0>] vm_mmap_pgoff+0x90/0xc0
       [<ffffffff81197d6c>] sys_mmap_pgoff+0x4c/0x190
       [<ffffffff81367d7e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8101eb42>] sys_mmap+0x22/0x30
       [<ffffffff81722fd9>] system_call_fastpath+0x16/0x1b
      
      Usual problem with the usual fix, add the appropriate calls to dma_mapping_error
      where appropriate
      
      Untested, as I don't have hardware, but its pretty straightforward
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Roger Luethi <rl@hellgate.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b4fe5fb