1. 09 3月, 2015 8 次提交
  2. 08 3月, 2015 4 次提交
  3. 07 3月, 2015 25 次提交
  4. 06 3月, 2015 3 次提交
    • S
      e1000: add dummy allocator to fix race condition between mtu change and netpoll · 08e83316
      Sabrina Dubroca 提交于
      There is a race condition between e1000_change_mtu's cleanups and
      netpoll, when we change the MTU across jumbo size:
      
      Changing MTU frees all the rx buffers:
          e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
              e1000_clean_rx_ring
      
      Then, close to the end of e1000_change_mtu:
          pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
              e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag
      
      And when we come back to do the rest of the MTU change:
          e1000_up -> e1000_configure -> e1000_configure_rx ->
              e1000_alloc_jumbo_rx_buffers
      
      alloc_jumbo finds the buffers already != NULL, since data (shared with
      page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
      or at least not what is expected when in jumbo state.
      
      This results in an unusable adapter (packets don't get through), and a
      NULL pointer dereference on the next call to e1000_clean_rx_ring
      (other mtu change, link down, shutdown):
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
      
          [...]
      
      Call Trace:
       [<ffffffff81195445>] put_page+0x55/0x60
       [<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200
       [<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60
       [<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0
       [<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840
       [<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170
       [<ffffffff81647050>] dev_set_mtu+0xa0/0x140
       [<ffffffff81664218>] do_setlink+0x218/0xac0
       [<ffffffff814459e9>] ? nla_parse+0xb9/0x120
       [<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890
       [<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40
       [<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100
       [<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260
      
      By setting the allocator to a dummy version, netpoll can't mess up our
      rx buffers.  The allocator is set back to a sane value in
      e1000_configure_rx.
      
      Fixes: edbbb3ca ("e1000: implement jumbo receive with partial descriptors")
      Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      08e83316
    • E
      e1000: call netif_carrier_off early on down · f9c029db
      Eliezer Tamir 提交于
      When bringing down an interface netif_carrier_off() should be
      one the first things we do, since this will prevent the stack
      from queuing more packets to this interface.
      This operation is very fast, and should make the device behave
      much nicer when trying to bring down an interface under load.
      
      Also, this would Do The Right Thing (TM) if this device has some
      sort of fail-over teaming and redirect traffic to the other IF.
      
      Move netif_carrier_off as early as possible.
      Signed-off-by: NEliezer Tamir <eliezer.tamir@linux.intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f9c029db
    • A
      igb: Make arrays on stack static const to avoid reallocation · b23c0cc5
      Alexander Duyck 提交于
      While addressing the pin problem I noticed that all of the pin register
      values where having to be pushed onto the stack each time the function was
      called.  To avoid that I am making them static const so that they should
      only need to be allocated once and we can avoid all the instructions to get
      them onto the stack..
      
      size before:
         text	   data	    bss	    dec	    hex	filename
       161477	  10512	      8	 171997	  29fdd	drivers/net/ethernet/intel/igb/igb.ko
      
      size after:
         text	   data	    bss	    dec	    hex	filename
       161205	  10512	      8	 171725	  29ecd	drivers/net/ethernet/intel/igb/igb.ko
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b23c0cc5