1. 29 1月, 2008 1 次提交
  2. 28 1月, 2008 3 次提交
  3. 26 1月, 2008 2 次提交
  4. 25 1月, 2008 7 次提交
  5. 23 1月, 2008 7 次提交
  6. 22 1月, 2008 1 次提交
  7. 21 1月, 2008 2 次提交
    • P
      [NET]: rtnl_link: fix use-after-free · 68365458
      Patrick McHardy 提交于
      When unregistering the rtnl_link_ops, all existing devices using
      the ops are destroyed. With nested devices this may lead to a
      use-after-free despite the use of for_each_netdev_safe() in case
      the upper device is next in the device list and is destroyed
      by the NETDEV_UNREGISTER notifier.
      
      The easy fix is to restart scanning the device list after removing
      a device. Alternatively we could add new devices to the front of
      the list to avoid having dependant devices follow the device they
      depend on. A third option would be to only restart scanning if
      dev->iflink of the next device matches dev->ifindex of the current
      one. For now this seems like the safest solution.
      
      With this patch, the veth rtnl_link_ops unregistration can use
      rtnl_link_unregister() directly since it now also handles destruction
      of multiple devices at once.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68365458
    • D
      [NET]: Fix interrupt semaphore corruption in Intel drivers. · 49d85c50
      David S. Miller 提交于
      Several of the Intel ethernet drivers keep an atomic counter used to
      manage when to actually hit the hardware with a disable or an enable.
      
      The way the net_rx_work() breakout logic works during a pending
      napi_disable() is that it simply unschedules the poll even if it
      still has work.
      
      This can potentially leave interrupts disabled, but that is OK
      because all of the drivers are about to disable interrupts
      anyways in all such code paths that do a napi_disable().
      
      Unfortunately, this trips up the semaphore used here in the Intel
      drivers.  If you hit this case, when you try to bring the interface
      back up it won't enable interrupts.  A reload of the driver module
      fixes it of course.
      
      So what we do is make sure all the sequences now go:
      
      	napi_disable();
      	atomic_set(&adapter->irq_sem, 0);
      	*_irq_disable();
      
      which makes sure the counter is always in the correct state.
      
      Reported by Robert Olsson.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49d85c50
  8. 19 1月, 2008 17 次提交