1. 13 2月, 2008 2 次提交
    • U
      [NET]: Fix comment for skb_pull_rcsum · fee54fa5
      Urs Thuermann 提交于
      Fix comment for skb_pull_rcsum
      Signed-off-by: NUrs Thuermann <urs@isnogud.escape.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fee54fa5
    • D
      [NDISC]: Fix race in generic address resolution · 69cc64d8
      David S. Miller 提交于
      Frank Blaschka provided the bug report and the initial suggested fix
      for this bug.  He also validated this version of this fix.
      
      The problem is that the access to neigh->arp_queue is inconsistent, we
      grab references when dropping the lock lock to call
      neigh->ops->solicit() but this does not prevent other threads of
      control from trying to send out that packet at the same time causing
      corruptions because both code paths believe they have exclusive access
      to the skb.
      
      The best option seems to be to hold the write lock on neigh->lock
      during the ->solicit() call.  I looked at all of the ndisc_ops
      implementations and this seems workable.  The only case that needs
      special care is the IPV4 ARP implementation of arp_solicit().  It
      wants to take neigh->lock as a reader to protect the header entry in
      neigh->ha during the emission of the soliciation.  We can simply
      remove the read lock calls to take care of that since holding the lock
      as a writer at the caller providers a superset of the protection
      afforded by the existing read locking.
      
      The rest of the ->solicit() implementations don't care whether the
      neigh is locked or not.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69cc64d8
  2. 08 2月, 2008 2 次提交
  3. 05 2月, 2008 1 次提交
  4. 04 2月, 2008 1 次提交
  5. 03 2月, 2008 1 次提交
  6. 02 2月, 2008 3 次提交
  7. 01 2月, 2008 4 次提交
  8. 29 1月, 2008 26 次提交