1. 13 Jun, 2008 3 commits
  2. 12 Jun, 2008 4 commits
    • David S. Miller's avatar
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller authored
      This reverts two changesets, ec3c0982
      ("[TCP]: TCP_DEFER_ACCEPT updates - process as established") and
      the follow-on bug fix 9ae27e0a
      
      
      ("tcp: Fix slab corruption with ipv6 and tcp6fuzz").
      
      This change causes several problems, first reported by Ingo Molnar
      as a distcc-over-loopback regression where connections were getting
      stuck.
      
      Ilpo Järvinen first spotted the locking problems.  The new function
      added by this code, tcp_defer_accept_check(), only has the
      child socket locked, yet it is modifying state of the parent
      listening socket.
      
      Fixing that is non-trivial at best, because we can't simply just grab
      the parent listening socket lock at this point, because it would
      create an ABBA deadlock.  The normal ordering is parent listening
      socket --> child socket, but this code path would require the
      reverse lock ordering.
      
      Next is a problem noticed by Vitaliy Gusev, he noted:
      
      ----------------------------------------
      >--- a/net/ipv4/tcp_timer.c
      >+++ b/net/ipv4/tcp_timer.c
      >@@ -481,6 +481,11 @@ static void tcp_keepalive_timer (unsigned long data)
      > 		goto death;
      > 	}
      >
      >+	if (tp->defer_tcp_accept.request && sk->sk_state == TCP_ESTABLISHED) {
      >+		tcp_send_active_reset(sk, GFP_ATOMIC);
      >+		goto death;
      
      Here socket sk is not attached to listening socket's request queue. tcp_done()
      will not call inet_csk_destroy_sock() (and tcp_v4_destroy_sock() which should
      release this sk) as socket is not DEAD. Therefore socket sk will be lost for
      freeing.
      ----------------------------------------
      
      Finally, Alexey Kuznetsov argues that there might not even be any
      real value or advantage to these new semantics even if we fix all
      of the bugs:
      
      ----------------------------------------
      Hiding from accept() sockets with only out-of-order data only
      is the only thing which is impossible with old approach. Is this really
      so valuable? My opinion: no, this is nothing but a new loophole
      to consume memory without control.
      ----------------------------------------
      
      So revert this thing for now.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec0a1966
    • David S. Miller's avatar
      ipv6: Fix duplicate initialization of rawv6_prot.destroy · f23d60de
      David S. Miller authored
      In changeset 22dd4850
      
      
      ("raw: Raw socket leak.") code was added so that we
      flush pending frames on raw sockets to avoid leaks.
      
      The ipv4 part was fine, but the ipv6 part was not
      done correctly.  Unlike the ipv4 side, the ipv6 code
      already has a .destroy method for rawv6_prot.
      
      So now there were two assignments to this member, and
      what the compiler does is use the last one, effectively
      making the ipv6 parts of that changeset a NOP.
      
      Fix this by removing the:
      
      	.destroy	   = inet6_destroy_sock,
      
      line, and adding an inet6_destroy_sock() call to the
      end of raw6_destroy().
      
      Noticed by Al Viro.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      f23d60de
    • Eilon Greenstein's avatar
      bnx2x: Updating the Maintainer · 24e3fcef
      Eilon Greenstein authored
      
      
      I would like to thank Eliezer Tamir for writing and maintaining the
      driver for the past two years. I will take over maintaining the bnx2x
      driver from now on.
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarEliezer Tamir <eliezert@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24e3fcef
    • David S. Miller's avatar
      net: Eliminate flush_scheduled_work() calls while RTNL is held. · 4bb073c0
      David S. Miller authored
      
      
      If the RTNL is held when we invoke flush_scheduled_work() we could
      deadlock.  One such case is linkwatch, it is a work struct which tries
      to grab the RTNL semaphore.
      
      The most common case are net driver ->stop() methods.  The
      simplest conversion is to instead use cancel_{delayed_}work_sync()
      explicitly on the various work struct the driver uses.
      
      This is an OK transformation because these work structs are doing
      things like resetting the chip, restarting link negotiation, and so
      forth.  And if we're bringing down the device, we're about to turn the
      chip off and reset it anways.  So if we cancel a pending work event,
      that's fine here.
      
      Some drivers were working around this deadlock by using a msleep()
      polling loop of some sort, and those cases are converted to instead
      use cancel_{delayed_}work_sync() as well.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bb073c0
  3. 11 Jun, 2008 19 commits
  4. 10 Jun, 2008 14 commits