1. 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
  2. 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
  3. 17 7月, 2013 7 次提交
  4. 15 7月, 2013 1 次提交
  5. 13 7月, 2013 4 次提交
    • 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
    • N
      atl1e: fix dma mapping warnings · 352900b5
      Neil Horman 提交于
      Recently had this backtrace reported:
      WARNING: at lib/dma-debug.c:937 check_unmap+0x47d/0x930()
      Hardware name: System Product Name
      ATL1E 0000:02:00.0: DMA-API: device driver failed to check map error[device
      address=0x00000000cbfd1000] [size=90 bytes] [mapped as single]
      Modules linked in: xt_conntrack nf_conntrack ebtable_filter ebtables
      ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt
      iTCO_vendor_support snd_hda_intel acpi_cpufreq mperf coretemp btrfs zlib_deflate
      snd_hda_codec snd_hwdep microcode raid6_pq libcrc32c snd_seq usblp serio_raw xor
      snd_seq_device joydev snd_pcm snd_page_alloc snd_timer snd lpc_ich i2c_i801
      soundcore mfd_core atl1e asus_atk0110 ata_generic pata_acpi radeon i2c_algo_bit
      drm_kms_helper ttm drm i2c_core pata_marvell uinput
      Pid: 314, comm: systemd-journal Not tainted 3.9.0-0.rc6.git2.3.fc19.x86_64 #1
      Call Trace:
       <IRQ>  [<ffffffff81069106>] warn_slowpath_common+0x66/0x80
       [<ffffffff8106916c>] warn_slowpath_fmt+0x4c/0x50
       [<ffffffff8138151d>] check_unmap+0x47d/0x930
       [<ffffffff810ad048>] ? sched_clock_cpu+0xa8/0x100
       [<ffffffff81381a2f>] debug_dma_unmap_page+0x5f/0x70
       [<ffffffff8137ce30>] ? unmap_single+0x20/0x30
       [<ffffffffa01569a1>] atl1e_intr+0x3a1/0x5b0 [atl1e]
       [<ffffffff810d53fd>] ? trace_hardirqs_off+0xd/0x10
       [<ffffffff81119636>] handle_irq_event_percpu+0x56/0x390
       [<ffffffff811199ad>] handle_irq_event+0x3d/0x60
       [<ffffffff8111cb6a>] handle_fasteoi_irq+0x5a/0x100
       [<ffffffff8101c36f>] handle_irq+0xbf/0x150
       [<ffffffff811dcb2f>] ? file_sb_list_del+0x3f/0x50
       [<ffffffff81073b10>] ? irq_enter+0x50/0xa0
       [<ffffffff8172738d>] do_IRQ+0x4d/0xc0
       [<ffffffff811dcb2f>] ? file_sb_list_del+0x3f/0x50
       [<ffffffff8171c6b2>] common_interrupt+0x72/0x72
       <EOI>  [<ffffffff810db5b2>] ? lock_release+0xc2/0x310
       [<ffffffff8109ea04>] lg_local_unlock_cpu+0x24/0x50
       [<ffffffff811dcb2f>] file_sb_list_del+0x3f/0x50
       [<ffffffff811dcb6d>] fput+0x2d/0xc0
       [<ffffffff811d8ea1>] filp_close+0x61/0x90
       [<ffffffff811fae4d>] __close_fd+0x8d/0x150
       [<ffffffff811d8ef0>] sys_close+0x20/0x50
       [<ffffffff81725699>] system_call_fastpath+0x16/0x1b
      
      The usual straighforward failure to check for dma_mapping_error after a map
      operation is completed.
      
      This patch should fix it, the reporter wandered off after filing this bz:
      https://bugzilla.redhat.com/show_bug.cgi?id=954170
      
      and I don't have hardware to test, but the fix is pretty straightforward, so I
      figured I'd post it for review.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Jay Cliburn <jcliburn@gmail.com>
      CC: Chris Snook <chris.snook@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      352900b5
    • H
      usb/net/r815x: fix cast to restricted __le32 · e7638524
      hayeswang 提交于
      >> drivers/net/usb/r815x.c:38:16: sparse: cast to restricted __le32
      >> drivers/net/usb/r815x.c:67:15: sparse: cast to restricted __le32
      >> drivers/net/usb/r815x.c:69:13: sparse: incorrect type in assignment (different base types)
         drivers/net/usb/r815x.c:69:13:    expected unsigned int [unsigned] [addressable] [assigned] [usertype] tmp
         drivers/net/usb/r815x.c:69:13:    got restricted __le32 [usertype] <noident>
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Spotted-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7638524
    • H
      usb/net/r8152: fix integer overflow in expression · 3ff25e3c
      hayeswang 提交于
      config: make ARCH=avr32 allyesconfig
      drivers/net/usb/r8152.c: In function 'rtl8152_start_xmit':
      drivers/net/usb/r8152.c:956: warning: integer overflow in expression
      
         955	memset(tx_desc, 0, sizeof(*tx_desc));
       > 956	tx_desc->opts1 = cpu_to_le32((len & TX_LEN_MASK) | TX_FS | TX_LS);
         957	tp->tx_skb = skb;
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Spotted-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ff25e3c
  6. 12 7月, 2013 24 次提交