1. 10 Nov, 2012 3 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6 · affd9a8d
      Linus Torvalds authored
      Pull cifs fixes from Jeff Layton.
      
      * 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
        cifs: Do not lookup hashed negative dentry in cifs_atomic_open
        cifs: fix potential buffer overrun in cifs.idmap handling code
      affd9a8d
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64 · 487bda54
      Linus Torvalds authored
      Pull arm64 fixes from Catalin Marinas:
       - correct argument type (pgprot_t) when calling __ioremap()
       - PCI_IOBASE virtual address change
       - use architected event for CPU cycle counter
       - fix ELF core dumping
       - select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION
       - missing completion for secondary CPU boot
       - booting on systems with all memory beyond 4GB
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
        arm64: mm: fix booting on systems with no memory below 4GB
        arm64: smp: add missing completion for secondary boot
        arm64: compat: select CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION
        arm64: elf: fix core dumping definitions for GP and FP registers
        arm64: perf: use architected event for CPU cycle counter
        arm64: Move PCI_IOBASE closer to MODULES_VADDR
        arm64: Use pgprot_t as the last argument when invoking __ioremap()
      487bda54
    • Linus Torvalds's avatar
      Merge tag 'stable/for-linus-3.7-rc5-tag' of... · 0020dd0b
      Linus Torvalds authored
      Merge tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen
      
      Pull Xen fixes from Konrad Rzeszutek Wilk:
       "There are three ARM compile fixes (we forgot to export certain
        functions and if the drivers are built as an module - we go belly-up).
      
        There is also an mismatch of irq_enter() / exit_idle() calls sequence
        which were fixed some time ago in other piece of codes, but failed to
        appear in the Xen code.
      
        Lastly a fix for to help in the field with troubleshooting in case we
        cannot get the appropriate parameter and also fallback code when
        working with very old hypervisors."
      
      Bug-fixes:
       - Fix compile issues on ARM.
       - Fix hypercall fallback code for old hypervisors.
       - Print out which HVM parameter failed if it fails.
       - Fix idle notifier call after irq_enter.
      
      * tag 'stable/for-linus-3.7-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
        xen/arm: Fix compile errors when drivers are compiled as modules (export more).
        xen/arm: Fix compile errors when drivers are compiled as modules.
        xen/generic: Disable fallback build on ARM.
        xen/events: fix RCU warning, or Call idle notifier after irq_enter()
        xen/hvm: If we fail to fetch an HVM parameter print out which flag it is.
        xen/hypercall: fix hypercall fallback code for very old hypervisors
      0020dd0b
  2. 09 Nov, 2012 28 commits
  3. 08 Nov, 2012 9 commits
    • Dave Chinner's avatar
      xfs: fix reading of wrapped log data · 6ce377af
      Dave Chinner authored
      Commit 44396476 ("xfs: reset buffer pointers before freeing them") in
      3.0-rc1 introduced a regression when recovering log buffers that
      wrapped around the end of log. The second part of the log buffer at
      the start of the physical log was being read into the header buffer
      rather than the data buffer, and hence recovery was seeing garbage
      in the data buffer when it got to the region of the log buffer that
      was incorrectly read.
      
      Cc: <stable@vger.kernel.org> # 3.0.x, 3.2.x, 3.4.x 3.6.x
      Reported-by: default avatarTorsten Kaiser <just.for.lkml@googlemail.com>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      6ce377af
    • Dave Chinner's avatar
      xfs: fix buffer shudown reference count mismatch · 03b1293e
      Dave Chinner authored
      When we shut down the filesystem, we have to unpin and free all the
      buffers currently active in the CIL. To do this we unpin and remove
      them in one operation as a result of a failed iclogbuf write. For
      buffers, we do this removal via a simultated IO completion of after
      marking the buffer stale.
      
      At the time we do this, we have two references to the buffer - the
      active LRU reference and the buf log item.  The LRU reference is
      removed by marking the buffer stale, and the active CIL reference is
      by the xfs_buf_iodone() callback that is run by
      xfs_buf_do_callbacks() during ioend processing (via the bp->b_iodone
      callback).
      
      However, ioend processing requires one more reference - that of the
      IO that it is completing. We don't have this reference, so we free
      the buffer prematurely and use it after it is freed. For buffers
      marked with XBF_ASYNC, this leads to assert failures in
      xfs_buf_rele() on debug kernels because the b_hold count is zero.
      
      Fix this by making sure we take the necessary IO reference before
      starting IO completion processing on the stale buffer, and set the
      XBF_ASYNC flag to ensure that IO completion processing removes all
      the active references from the buffer to ensure it is fully torn
      down.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      03b1293e
    • Dave Chinner's avatar
      xfs: don't vmap inode cluster buffers during free · 4b62acfe
      Dave Chinner authored
      Inode buffers do not need to be mapped as inodes are read or written
      directly from/to the pages underlying the buffer. This fixes a
      regression introduced by commit 611c9946 ("xfs: make XBF_MAPPED the
      default behaviour").
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      4b62acfe
    • Dave Chinner's avatar
      xfs: invalidate allocbt blocks moved to the free list · ca250b1b
      Dave Chinner authored
      When we free a block from the alloc btree tree, we move it to the
      freelist held in the AGFL and mark it busy in the busy extent tree.
      This typically happens when we merge btree blocks.
      
      Once the transaction is committed and checkpointed, the block can
      remain on the free list for an indefinite amount of time.  Now, this
      isn't the end of the world at this point - if the free list is
      shortened, the buffer is invalidated in the transaction that moves
      it back to free space. If the buffer is allocated as metadata from
      the free list, then all the modifications getted logged, and we have
      no issues, either. And if it gets allocated as userdata direct from
      the freelist, it gets invalidated and so will never get written.
      
      However, during the time it sits on the free list, pressure on the
      log can cause the AIL to be pushed and the buffer that covers the
      block gets pushed for write. IOWs, we end up writing a freed
      metadata block to disk. Again, this isn't the end of the world
      because we know from the above we are only writing to free space.
      
      The problem, however, is for validation callbacks. If the block was
      on old btree root block, then the level of the block is going to be
      higher than the current tree root, and so will fail validation.
      There may be other inconsistencies in the block as well, and
      currently we don't care because the block is in free space. Shutting
      down the filesystem because a freed block doesn't pass write
      validation, OTOH, is rather unfriendly.
      
      So, make sure we always invalidate buffers as they move from the
      free space trees to the free list so that we guarantee they never
      get written to disk while on the free list.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarPhil White <pwhite@sgi.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      ca250b1b
    • Dave Chinner's avatar
      xfs: silence uninitialised f.file warning. · 1e7acbb7
      Dave Chinner authored
      Uninitialised variable build warning introduced by 2903ff01 ("switch
      simple cases of fget_light to fdget"), gcc is not smart enough to
      work out that the variable is not used uninitialised, and the commit
      removed the initialisation at declaration that the old variable had.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      1e7acbb7
    • Dave Chinner's avatar
      xfs: growfs: don't read garbage for new secondary superblocks · eaef8543
      Dave Chinner authored
      When updating new secondary superblocks in a growfs operation, the
      superblock buffer is read from the newly grown region of the
      underlying device. This is not guaranteed to be zero, so violates
      the underlying assumption that the unused parts of superblocks are
      zero filled. Get a new buffer for these secondary superblocks to
      ensure that the unused regions are zero filled correctly.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarCarlos Maiolino <cmaiolino@redhat.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      eaef8543
    • Dave Chinner's avatar
      xfs: move allocation stack switch up to xfs_bmapi_allocate · 1f3c785c
      Dave Chinner authored
      Switching stacks are xfs_alloc_vextent can cause deadlocks when we
      run out of worker threads on the allocation workqueue. This can
      occur because xfs_bmap_btalloc can make multiple calls to
      xfs_alloc_vextent() and even if xfs_alloc_vextent() fails it can
      return with the AGF locked in the current allocation transaction.
      
      If we then need to make another allocation, and all the allocation
      worker contexts are exhausted because the are blocked waiting for
      the AGF lock, holder of the AGF cannot get it's xfs-alloc_vextent
      work completed to release the AGF.  Hence allocation effectively
      deadlocks.
      
      To avoid this, move the stack switch one layer up to
      xfs_bmapi_allocate() so that all of the allocation attempts in a
      single switched stack transaction occur in a single worker context.
      This avoids the problem of an allocation being blocked waiting for
      a worker thread whilst holding the AGF.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      1f3c785c
    • Dave Chinner's avatar
      xfs: introduce XFS_BMAPI_STACK_SWITCH · 326c0355
      Dave Chinner authored
      Certain allocation paths through xfs_bmapi_write() are in situations
      where we have limited stack available. These are almost always in
      the buffered IO writeback path when convertion delayed allocation
      extents to real extents.
      
      The current stack switch occurs for userdata allocations, which
      means we also do stack switches for preallocation, direct IO and
      unwritten extent conversion, even those these call chains have never
      been implicated in a stack overrun.
      
      Hence, let's target just the single stack overun offended for stack
      switches. To do that, introduce a XFS_BMAPI_STACK_SWITCH flag that
      the caller can pass xfs_bmapi_write() to indicate it should switch
      stacks if it needs to do allocation.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      326c0355
    • Mark Tinguely's avatar
      xfs: zero allocation_args on the kernel stack · 408cc4e9
      Mark Tinguely authored
      Zero the kernel stack space that makes up the xfs_alloc_arg structures.
      Signed-off-by: default avatarMark Tinguely <tinguely@sgi.com>
      Reviewed-by: default avatarBen Myers <bpm@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      408cc4e9