1. 27 3月, 2008 2 次提交
    • T
      SVCRDMA: Check num_sge when setting LAST_CTXT bit · c8237a5f
      Tom Tucker 提交于
      The RDMACTXT_F_LAST_CTXT bit was getting set incorrectly
      when the last chunk in the read-list spanned multiple pages. This
      resulted in a kernel panic when the wrong context was used to
      build the RPC iovec page list.
      
      RDMA_READ is used to fetch RPC data from the client for
      NFS_WRITE requests. A scatter-gather is used to map the
      advertised client side buffer to the server-side iovec and
      associated page list.
      
      WR contexts are used to convey which scatter-gather entries are
      handled by each WR. When the write data is large, a single RPC may
      require multiple RDMA_READ requests so the contexts for a single RPC
      are chained together in a linked list. The last context in this list
      is marked with a bit RDMACTXT_F_LAST_CTXT so that when this WR completes,
      the CQ handler code can enqueue the RPC for processing.
      
      The code in rdma_read_xdr was setting this bit on the last two
      contexts on this list when the last read-list chunk spanned multiple
      pages. This caused the svc_rdma_recvfrom logic to incorrectly build
      the RPC and caused the kernel to crash because the second-to-last
      context doesn't contain the iovec page list.
      
      Modified the condition that sets this bit so that it correctly detects
      the last context for the RPC.
      Signed-off-by: NTom Tucker <tom@opengridcomputing.com>
      Tested-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c8237a5f
    • L
      Revert "PCI: remove transparent bridge sizing" · 12c22d6e
      Linus Torvalds 提交于
      This reverts commit 8fa5913d, which
      caused various interesting problems for people, including wrong resource
      allocations.  See for example bugzilla entry "2.6.25-rc2: ohci1394
      problem (MMIO broken)" at
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=10080
      
      And Gary Hade says:
      
       "The same change had also exposed an issue reported by Paul Martin that
        has been causing an Oops while hotplugging ThinkPads to a ThinkPad
        Dock II.  See
      
      	http://lkml.org/lkml/2008/2/19/405
      	http://bugzilla.kernel.org/show_bug.cgi?id=9961
      
        I have a fix for the ThinkPad docking Oops but if the issue being
        discussed here is caused by the transparent bridge sizing removal
        change I totally agree that it should be reverted."
      
        The transparent bridge sizing removal change was motivated by
        insufficient PCI memory resource for a transparent bridge window that
        was being created as a result of expansion ROM(s) being included in
        the transparent bridge sizing calculations.
      
        A later "PCI: Remove default PCI expansion ROM memory allocation"
        change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the
        expansion ROM(s) from the transparent bridge sizing calculations which
        actually resolves the original issue in a different manner.  So, even
        if the "PCI: remove transparent bridge sizing" is not problematic it
        is no longer needed anyway."
      Identified-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Tested-by: NThomas Meyer <thomas@m3y3r.de>
      Acked-by: NGary Hade <garyhade@us.ibm.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      12c22d6e
  2. 26 3月, 2008 4 次提交
  3. 25 3月, 2008 34 次提交