1. 28 10月, 2014 3 次提交
  2. 27 10月, 2014 1 次提交
    • D
      xen-netfront: always keep the Rx ring full of requests · 1f3c2eba
      David Vrabel 提交于
      A full Rx ring only requires 1 MiB of memory.  This is not enough
      memory that it is useful to dynamically scale the number of Rx
      requests in the ring based on traffic rates, because:
      
      a) Even the full 1 MiB is a tiny fraction of a typically modern Linux
         VM (for example, the AWS micro instance still has 1 GiB of memory).
      
      b) Netfront would have used up to 1 MiB already even with moderate
         data rates (there was no adjustment of target based on memory
         pressure).
      
      c) Small VMs are going to typically have one VCPU and hence only one
         queue.
      
      Keeping the ring full of Rx requests handles bursty traffic better
      than trying to converge on an optimal number of requests to keep
      filled.
      
      On a 4 core host, an iperf -P 64 -t 60 run from dom0 to a 4 VCPU guest
      improved from 5.1 Gbit/s to 5.6 Gbit/s.  Gains with more bursty
      traffic are expected to be higher.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f3c2eba
  3. 26 10月, 2014 3 次提交
  4. 25 10月, 2014 4 次提交
  5. 24 10月, 2014 12 次提交
  6. 23 10月, 2014 6 次提交
  7. 22 10月, 2014 2 次提交
    • G
      enic: Do not call napi_disable when preemption is disabled. · 39dc90c1
      Govindarajulu Varadarajan 提交于
      In enic_stop, we disable preemption using local_bh_disable(). We disable
      preemption to wait for busy_poll to finish.
      
      napi_disable should not be called here as it might sleep.
      
      Moving napi_disable() call out side of local_bh_disable.
      
      BUG: sleeping function called from invalid context at include/linux/netdevice.h:477
      in_atomic(): 1, irqs_disabled(): 0, pid: 443, name: ifconfig
      INFO: lockdep is turned off.
      Preemption disabled at:[<ffffffffa029c5c4>] enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      
      CPU: 31 PID: 443 Comm: ifconfig Not tainted 3.17.0-netnext-05504-g59f35b81 #268
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       ffff8800dac10000 ffff88020b8dfcb8 ffffffff8148a57c 0000000000000000
       ffff88020b8dfcd0 ffffffff8107e253 ffff8800dac12a40 ffff88020b8dfd10
       ffffffffa029305b ffff88020b8dfd48 ffff8800dac10000 ffff88020b8dfd48
      Call Trace:
       [<ffffffff8148a57c>] dump_stack+0x4e/0x7a
       [<ffffffff8107e253>] __might_sleep+0x123/0x1a0
       [<ffffffffa029305b>] enic_stop+0xdb/0x4d0 [enic]
       [<ffffffff8138ed7d>] __dev_close_many+0x9d/0xf0
       [<ffffffff8138ef81>] __dev_close+0x31/0x50
       [<ffffffff813974a8>] __dev_change_flags+0x98/0x160
       [<ffffffff81397594>] dev_change_flags+0x24/0x60
       [<ffffffff814085fd>] devinet_ioctl+0x63d/0x710
       [<ffffffff81139c16>] ? might_fault+0x56/0xc0
       [<ffffffff81409ef5>] inet_ioctl+0x65/0x90
       [<ffffffff813768e0>] sock_do_ioctl+0x20/0x50
       [<ffffffff81376ebb>] sock_ioctl+0x20b/0x2e0
       [<ffffffff81197250>] do_vfs_ioctl+0x2e0/0x500
       [<ffffffff81492619>] ? sysret_check+0x22/0x5d
       [<ffffffff81285f23>] ? __this_cpu_preempt_check+0x13/0x20
       [<ffffffff8109fe19>] ? trace_hardirqs_on_caller+0x119/0x270
       [<ffffffff811974ac>] SyS_ioctl+0x3c/0x80
       [<ffffffff814925ed>] system_call_fastpath+0x1a/0x1f
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39dc90c1
    • G
      enic: fix possible deadlock in enic_stop/ enic_rfs_flw_tbl_free · b6931c9b
      Govindarajulu Varadarajan 提交于
      The following warning is shown when spinlock debug is enabled.
      
      This occurs when enic_flow_may_expire timer function is running and
      enic_stop is called on same CPU.
      
      Fix this by using spink_lock_bh().
      
      =================================
      [ INFO: inconsistent lock state ]
      3.17.0-netnext-05504-g59f35b81 #268 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      ifconfig/443 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&enic->rfs_h.lock)->rlock){+.?...}, at:
      enic_rfs_flw_tbl_free+0x34/0xd0 [enic]
      {IN-SOFTIRQ-W} state was registered at:
        [<ffffffff810a25af>] __lock_acquire+0x83f/0x21c0
        [<ffffffff810a45f2>] lock_acquire+0xa2/0xd0
        [<ffffffff814913fc>] _raw_spin_lock+0x3c/0x80
        [<ffffffffa029c3d5>] enic_flow_may_expire+0x25/0x130[enic]
        [<ffffffff810bcd07>] call_timer_fn+0x77/0x100
        [<ffffffff810bd8e3>] run_timer_softirq+0x1e3/0x270
        [<ffffffff8105f9ae>] __do_softirq+0x14e/0x280
        [<ffffffff8105fdae>] irq_exit+0x8e/0xb0
        [<ffffffff8103da0f>] smp_apic_timer_interrupt+0x3f/0x50
        [<ffffffff81493742>] apic_timer_interrupt+0x72/0x80
        [<ffffffff81018143>] default_idle+0x13/0x20
        [<ffffffff81018a6a>] arch_cpu_idle+0xa/0x10
        [<ffffffff81097676>] cpu_startup_entry+0x2c6/0x330
        [<ffffffff8103b7ad>] start_secondary+0x21d/0x290
      irq event stamp: 2997
      hardirqs last  enabled at (2997): [<ffffffff81491865>] _raw_spin_unlock_irqrestore+0x65/0x90
      hardirqs last disabled at (2996): [<ffffffff814915e6>] _raw_spin_lock_irqsave+0x26/0x90
      softirqs last  enabled at (2968): [<ffffffff813b57a3>] dev_deactivate_many+0x213/0x260
      softirqs last disabled at (2966): [<ffffffff813b5783>] dev_deactivate_many+0x1f3/0x260
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&enic->rfs_h.lock)->rlock);
        <Interrupt>
          lock(&(&enic->rfs_h.lock)->rlock);
      
       *** DEADLOCK ***
      Reported-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6931c9b
  8. 20 10月, 2014 1 次提交
    • I
      ax88179_178a: fix bonding failure · 95ff8868
      Ian Morgan 提交于
      The following patch fixes a bug which causes the ax88179_178a driver to be
      incapable of being added to a bond.
      
      When I brought up the issue with the bonding maintainers, they indicated
      that the real problem was with the NIC driver which must return zero for
      success (of setting the MAC address). I see that several other NIC drivers
      follow that pattern by either simply always returing zero, or by passing
      through a negative (error) result while rewriting any positive return code
      to zero. With that same philisophy applied to the ax88179_178a driver, it
      allows it to work correctly with the bonding driver.
      
      I believe this is suitable for queuing in -stable, as it's a small, simple,
      and obvious fix that corrects a defect with no other known workaround.
      
      This patch is against vanilla 3.17(.0).
      Signed-off-by: NIan Morgan <imorgan@primordial.ca>
      
       drivers/net/usb/ax88179_178a.c |    7 ++++++-
       1 file changed, 6 insertions(+), 1 deletion(-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      95ff8868
  9. 18 10月, 2014 6 次提交
  10. 16 10月, 2014 2 次提交