1. 27 6月, 2008 7 次提交
  2. 24 6月, 2008 1 次提交
  3. 20 6月, 2008 2 次提交
  4. 18 6月, 2008 5 次提交
  5. 17 6月, 2008 6 次提交
  6. 15 6月, 2008 4 次提交
  7. 13 6月, 2008 4 次提交
    • D
      pagemap: pass mm into pagewalkers · 2165009b
      Dave Hansen 提交于
      We need this at least for huge page detection for now, because powerpc
      needs the vm_area_struct to be able to determine whether a virtual address
      is referring to a huge page (its pmd_huge() doesn't work).
      
      It might also come in handy for some of the other users.
      Signed-off-by: NDave Hansen <dave@linux.vnet.ibm.com>
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2165009b
    • M
      cciss: add new hardware support · 24aac480
      Mike Miller 提交于
      Add support for the next generation of HP Smart Array SAS/SATA
      controllers.  Shipping date is late Fall 2008.
      
      Bump the driver version to 3.6.20 to reflect the new hardware support from
      patch 1 of this set.
      Signed-off-by: NMike Miller <mike.miller@hp.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      24aac480
    • B
      proc_fs.h: move struct mm_struct forward-declaration · 57d3c64f
      Ben Nizette 提交于
      Move the forward-declaration of struct mm_struct a little way up
      proc_fs.h.  This fixes a bunch of "'struct mm_struct' declared inside
      parameter list" warnings with CONFIG_PROC_FS=n
      Signed-off-by: NBen Nizette <bn@niasdigital.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      57d3c64f
    • D
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      ec0a1966
  8. 12 6月, 2008 10 次提交
  9. 11 6月, 2008 1 次提交