1. 10 12月, 2014 3 次提交
  2. 09 12月, 2014 2 次提交
    • E
      net: mvneta: fix race condition in mvneta_tx() · 5f478b41
      Eric Dumazet 提交于
      mvneta_tx() dereferences skb to get skb->len too late,
      as hardware might have completed the transmit and TX completion
      could have freed the skb from another cpu.
      
      Fixes: 71f6d1b3 ("net: mvneta: replace Tx timer with a real interrupt")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f478b41
    • W
      net: mvneta: fix Tx interrupt delay · aebea2ba
      willy tarreau 提交于
      The mvneta driver sets the amount of Tx coalesce packets to 16 by
      default. Normally that does not cause any trouble since the driver
      uses a much larger Tx ring size (532 packets). But some sockets
      might run with very small buffers, much smaller than the equivalent
      of 16 packets. This is what ping is doing for example, by setting
      SNDBUF to 324 bytes rounded up to 2kB by the kernel.
      
      The problem is that there is no documented method to force a specific
      packet to emit an interrupt (eg: the last of the ring) nor is it
      possible to make the NIC emit an interrupt after a given delay.
      
      In this case, it causes trouble, because when ping sends packets over
      its raw socket, the few first packets leave the system, and the first
      15 packets will be emitted without an IRQ being generated, so without
      the skbs being freed. And since the socket's buffer is small, there's
      no way to reach that amount of packets, and the ping ends up with
      "send: no buffer available" after sending 6 packets. Running with 3
      instances of ping in parallel is enough to hide the problem, because
      with 6 packets per instance, that's 18 packets total, which is enough
      to grant a Tx interrupt before all are sent.
      
      The original driver in the LSP kernel worked around this design flaw
      by using a software timer to clean up the Tx descriptors. This timer
      was slow and caused terrible network performance on some Tx-bound
      workloads (such as routing) but was enough to make tools like ping
      work correctly.
      
      Instead here, we simply set the packet counts before interrupt to 1.
      This ensures that each packet sent will produce an interrupt. NAPI
      takes care of coalescing interrupts since the interrupt is disabled
      once generated.
      
      No measurable performance impact nor CPU usage were observed on small
      nor large packets, including when saturating the link on Tx, and this
      fixes tools like ping which rely on too small a send buffer. If one
      wants to increase this value for certain workloads where it is safe
      to do so, "ethtool -C $dev tx-frames" will override this default
      setting.
      
      This fix needs to be applied to stable kernels starting with 3.10.
      Tested-By: NMaggie Mae Roxas <maggie.mae.roxas@gmail.com>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aebea2ba
  3. 06 12月, 2014 3 次提交
  4. 04 12月, 2014 1 次提交
  5. 03 12月, 2014 5 次提交
    • H
    • S
      xen-netfront: Remove BUGs on paged skb data which crosses a page boundary · 8d609725
      Seth Forshee 提交于
      These BUGs can be erroneously triggered by frags which refer to
      tail pages within a compound page. The data in these pages may
      overrun the hardware page while still being contained within the
      compound page, but since compound_order() evaluates to 0 for tail
      pages the assertion fails. The code already iterates through
      subsequent pages correctly in this scenario, so the BUGs are
      unnecessary and can be removed.
      
      Fixes: f36c3747 ("xen/netfront: handle compound page fragments on transmit")
      Cc: <stable@vger.kernel.org> # 3.7+
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Reviewed-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d609725
    • P
      drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 · f5475cc4
      Petr Mladek 提交于
      I was unable too boot 3.18.0-rc6 because of the following kernel
      panic in drm_calc_vbltimestamp_from_scanoutpos():
      
          [drm] Initialized drm 1.1.0 20060810
          [drm] radeon kernel modesetting enabled.
          [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
          [drm] register mmio base: 0xC8400000
          [drm] register mmio size: 65536
          radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
          radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
          [drm] Detected VRAM RAM=128M, BAR=128M
          [drm] RAM width 16bits DDR
          [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
          [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
          [TTM] Initializing pool allocator
          [TTM] Initializing DMA pool allocator
          [drm] radeon: 16M of VRAM memory ready
          [drm] radeon: 512M of GTT memory ready.
          [drm] GART: num cpu pages 131072, num gpu pages 131072
          [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
          radeon 0000:0b:01.0: WB disabled
          radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
          [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
          [drm] Driver supports precise vblank timestamp query.
          [drm] radeon: irq initialized.
          [drm] Loading R100 Microcode
          radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
          radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
          [drm:r100_cp_init] *ERROR* Failed to load firmware!
          radeon 0000:0b:01.0: failed initializing CP (-2).
          radeon 0000:0b:01.0: Disabling GPU acceleration
          [drm] radeon: cp finalized
          BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
          IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          PGD 0
          Oops: 0000 [#1] SMP
          Modules linked in:
          CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
          Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
          task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
          RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
          RSP: 0000:ffff880234da7918  EFLAGS: 00010086
          RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
          RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
          RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
          R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
          R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
          FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
          CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
          Stack:
           ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
           ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
           ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
          Call Trace:
           [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
           [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
           [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
           [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
           [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
           [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
           [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
           [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
           [<ffffffff8156c07e>] r100_init+0x26e/0x410
           [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
           [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
           [<ffffffff81506965>] drm_dev_register+0xb5/0x110
           [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
           [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
           [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
           [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
           [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
           [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
           [<ffffffff816340a0>] ? __device_attach+0x40/0x40
           [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
           [<ffffffff8163378e>] driver_attach+0x1e/0x20
           [<ffffffff81633390>] bus_add_driver+0x180/0x240
           [<ffffffff81634914>] driver_register+0x64/0xf0
           [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
           [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
           [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
           [<ffffffff821dc908>] radeon_init+0x97/0xb5
           [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
           [<ffffffff810e3278>] ? __wake_up+0x48/0x60
           [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
           [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
           [<ffffffff818a78fe>] kernel_init+0xe/0xf0
           [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
           [<ffffffff818a78f0>] ? rest_init+0x80/0x80
          Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
          RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
           RSP <ffff880234da7918>
          CR2: 000000000000025c
          ---[ end trace ad2c0aadf48e2032 ]---
          Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
      
      It has helped me to add a NULL pointer check that was suggested at
      http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html
      
      I am not familiar with the code. But the change looks sane
      and we need something fast at this stage of 3.18 development.
      Suggested-by: NHelge Deller <deller@gmx.de>
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Tested-by: NPetr Mladek <pmladek@suse.cz>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f5475cc4
    • M
      a08b588e
    • C
      drm/radeon: sync all BOs involved in a CS v2 · 86b27638
      Christian König 提交于
      Not just the userspace relocs, otherwise we won't wait
      for a swapped out page tables to be swapped in again.
      
      v2: rebased on Alex current drm-fixes-3.18
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      86b27638
  6. 02 12月, 2014 5 次提交
  7. 30 11月, 2014 4 次提交
    • M
      sh_eth: Fix sleeping function called from invalid context · 7fa2955f
      Mitsuhiro Kimura 提交于
      This resolves the following bug which can be reproduced by building the
      kernel with CONFIG_DEBUG_ATOMIC_SLEEP=y and reading network statistics
      while the network interface is down.
      
      e.g.:
      
      ifconfig eth0 down
      cat /sys/class/net/eth0/statistics/tx_errors
      
      ----
      [ 1238.161349] BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:952
      [ 1238.188279] in_atomic(): 1, irqs_disabled(): 0, pid: 1388, name: cat
      [ 1238.207425] CPU: 0 PID: 1388 Comm: cat Not tainted 3.10.31-ltsi-00046-gefa0b46 #1087
      [ 1238.230737] Backtrace:
      [ 1238.238123] [<c0012e64>] (dump_backtrace+0x0/0x10c) from [<c0013000>] (show_stack+0x18/0x1c)
      [ 1238.263499]  r6:000003b8 r5:c06160c0 r4:c0669e00 r3:00404000
      [ 1238.280583] [<c0012fe8>] (show_stack+0x0/0x1c) from [<c04515a4>] (dump_stack+0x20/0x28)
      [ 1238.304631] [<c0451584>] (dump_stack+0x0/0x28) from [<c004970c>] (__might_sleep+0xf8/0x118)
      [ 1238.329734] [<c0049614>] (__might_sleep+0x0/0x118) from [<c02465ac>] (__pm_runtime_resume+0x38/0x90)
      [ 1238.357170]  r7:d616f000 r6:c049c458 r5:00000004 r4:d6a17210
      [ 1238.374251] [<c0246574>] (__pm_runtime_resume+0x0/0x90) from [<c029b1c4>] (sh_eth_get_stats+0x44/0x280)
      [ 1238.402468]  r7:d616f000 r6:c049c458 r5:d5c21000 r4:d5c21000
      [ 1238.419552] [<c029b180>] (sh_eth_get_stats+0x0/0x280) from [<c03ae39c>] (dev_get_stats+0x54/0x88)
      [ 1238.446204]  r5:d5c21000 r4:d5ed7e08
      [ 1238.456980] [<c03ae348>] (dev_get_stats+0x0/0x88) from [<c03c677c>] (netstat_show.isra.15+0x54/0x9c)
      [ 1238.484413]  r6:d5c21000 r5:d5c21238 r4:00000028 r3:00000001
      [ 1238.501495] [<c03c6728>] (netstat_show.isra.15+0x0/0x9c) from [<c03c69b8>] (show_tx_errors+0x18/0x1c)
      [ 1238.529196]  r7:d5f945d8 r6:d5f945c0 r5:c049716c r4:c0650e7c
      [ 1238.546279] [<c03c69a0>] (show_tx_errors+0x0/0x1c) from [<c023963c>] (dev_attr_show+0x24/0x50)
      [ 1238.572157] [<c0239618>] (dev_attr_show+0x0/0x50) from [<c010c148>] (sysfs_read_file+0xb0/0x140)
      [ 1238.598554]  r5:c049716c r4:d5c21240
      [ 1238.609326] [<c010c098>] (sysfs_read_file+0x0/0x140) from [<c00b9ee4>] (vfs_read+0xb0/0x13c)
      [ 1238.634679] [<c00b9e34>] (vfs_read+0x0/0x13c) from [<c00ba0ac>] (SyS_read+0x44/0x74)
      [ 1238.657944]  r8:bef45bf0 r7:00000000 r6:d6ac0600 r5:00000000 r4:00000000
      [ 1238.678172] [<c00ba068>] (SyS_read+0x0/0x74) from [<c000eec0>] (ret_fast_syscall+0x0/0x30)
      ----
      Signed-off-by: NMitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
      Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7fa2955f
    • H
      stmmac: platform: Move plat_dat checking earlier · 28603d13
      Huacai Chen 提交于
      Original code only check/alloc plat_dat for the CONFIG_OF case, this
      patch check/alloc it earlier and unconditionally to avoid kernel build
      warnings:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
      stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
      
      V2: Fix coding style.
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28603d13
    • M
      sh_eth: Fix skb alloc size and alignment adjust rule. · 4d6a949c
      Mitsuhiro Kimura 提交于
      In the current driver, allocation size of skb does not care the alignment
      adjust after allocation.
      And also, in the current implementation, buffer alignment method by
      sh_eth_set_receive_align function has a bug that this function displace
      buffer start address forcedly when the alignment is corrected.
      In the result, tail of the skb will exceed allocated area and kernel panic
      will be occurred.
      This patch fix this issue.
      Signed-off-by: NMitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
      Signed-off-by: NYoshihiro Kaneko <ykaneko0929@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d6a949c
    • T
      bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes · f6c6fda4
      Thomas Graf 提交于
      Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support")
      Reported-by: NJohn Fastabend <john.fastabend@gmail.com>
      Cc: Scott Feldman <sfeldma@cumulusnetworks.com>
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6c6fda4
  8. 28 11月, 2014 1 次提交
  9. 27 11月, 2014 8 次提交
  10. 26 11月, 2014 8 次提交