12 Oct, 2011

5 commits

  • Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Instead of passing the block number and mount structure explicitly
    get them off the bp and fix make the argument order more natural.

    Also move it to xfs_buf.c and stop printing the device name given
    that we already get the fs name as part of xfs_alert, and we know
    what device is operates on because of the caller that gets printed,
    finally rename it to xfs_buf_ioerror_alert and pass __func__ as
    argument where it makes sense.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Remove the xfs_buf_relse from xfs_bwrite and let the caller handle it to
    mirror the delwri and read paths.

    Also remove the mount pointer passed to xfs_bwrite, which is superflous now
    that we have a mount pointer in the buftarg.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Unify the ways we add buffers to the delwri queue by always calling
    xfs_buf_delwri_queue directly. The xfs_bdwrite functions is removed and
    opencoded in its callers, and the two places setting XBF_DELWRI while a
    buffer is locked and expecting xfs_buf_unlock to pick it up are converted
    to call xfs_buf_delwri_queue directly, too. Also replace the
    XFS_BUF_UNDELAYWRITE macro with direct calls to xfs_buf_delwri_dequeue
    to make the explicit queuing/dequeuing more obvious.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Dave Chinner
    Signed-off-by: Alex Elder

    Christoph Hellwig
     

13 Aug, 2011

2 commits


08 Aug, 2011

1 commit


27 Jul, 2011

1 commit


26 Jul, 2011

6 commits


13 Jul, 2011

1 commit


08 Jul, 2011

3 commits

  • All other xfs_buf_get/read-like helpers return the buffer locked, make sure
    xfs_buf_get_uncached isn't different for no reason. Half of the callers
    already lock it directly after, and the others probably should also keep
    it locked if only for consistency and beeing able to use xfs_buf_rele,
    but I'll leave that for later.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • Rename xfs_buf_cond_lock and reverse it's return value to fit most other
    trylock operations in the Kernel and XFS (with the exception of down_trylock,
    after which xfs_buf_cond_lock was modelled), and replace xfs_buf_lock_val
    with an xfs_buf_islocked for use in asserts, or and opencoded variant in
    tracing. remove the XFS_BUF_* wrappers for all the locking helpers.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     
  • Micro-optimize various comparisms by always byteswapping the constant
    instead of the variable, which allows to do the swap at compile instead
    of runtime.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Alex Elder
    Reviewed-by: Dave Chinner

    Christoph Hellwig
     

20 May, 2011

1 commit

  • When we free a vmapped buffer, we need to ensure the vmap address
    and length we free is the same as when it was allocated. In various
    places in the log code we change the memory the buffer is pointing
    to before issuing IO, but we never reset the buffer to point back to
    it's original memory (or no memory, if that is the case for the
    buffer).

    As a result, when we free the buffer it points to memory that is
    owned by something else and attempts to unmap and free it. Because
    the range does not match any known mapped range, it can trigger
    BUG_ON() traps in the vmap code, and potentially corrupt the vmap
    area tracking.

    Fix this by always resetting these buffers to their original state
    before freeing them.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Dave Chinner
     

31 Mar, 2011

1 commit


07 Mar, 2011

1 commit

  • Convert the xfs log operations to use the new error logging
    interfaces. This removes the xlog_{warn,panic} wrappers and makes
    almost all errors emit the device they belong to instead of just
    refering to "XFS".

    Signed-off-by: Dave Chinner
    Reviewed-by: Alex Elder
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

12 Jan, 2011

1 commit

  • We currently have a global error message buffer in cmn_err that is
    protected by a spin lock that disables interrupts. Recently there
    have been reports of NMI timeouts occurring when the console is
    being flooded by SCSI error reports due to cmn_err() getting stuck
    trying to print to the console while holding this lock (i.e. with
    interrupts disabled). The NMI watchdog is seeing this CPU as
    non-responding and so is triggering a panic. While the trigger for
    the reported case is SCSI errors, pretty much anything that spams
    the kernel log could cause this to occur.

    Realistically the only reason that we have the intemediate message
    buffer is to prepend the correct kernel log level prefix to the log
    message. The only reason we have the lock is to protect the global
    message buffer and the only reason the message buffer is global is
    to keep it off the stack. Hence if we can avoid needing a global
    message buffer we avoid needing the lock, and we can do this with a
    small amount of cleanup and some preprocessor tricks:

    1. clean up xfs_cmn_err() panic mask functionality to avoid
    needing debug code in xfs_cmn_err()
    2. remove the couple of "!" message prefixes that still exist that
    the existing cmn_err() code steps over.
    3. redefine CE_* levels directly to KERN_*
    4. redefine cmn_err() and friends to use printk() directly
    via variable argument length macros.

    By doing this, we can completely remove the cmn_err() code and the
    lock that is causing the problems, and rely solely on printk()
    serialisation to ensure that we don't get garbled messages.

    A series of followup patches is really needed to clean up all the
    cmn_err() calls and related messages properly, but that results in a
    series that is not easily back portable to enterprise kernels. Hence
    this initial fix is only to address the direct problem in the lowest
    impact way possible.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Dave Chinner
     

21 Dec, 2010

2 commits

  • log->l_tail_lsn is currently protected by the log grant lock. The
    lock is only needed for serialising readers against writers, so we
    don't really need the lock if we make the l_tail_lsn variable an
    atomic. Converting the l_tail_lsn variable to an atomic64_t means we
    can start to peel back the grant lock from various operations.

    Also, provide functions to safely crack an atomic LSN variable into
    it's component pieces and to recombined the components into an
    atomic variable. Use them where appropriate.

    This also removes the need for explicitly holding a spinlock to read
    the l_tail_lsn on 32 bit platforms.

    Signed-off-by: Dave Chinner

    Dave Chinner
     
  • Prepare for switching the grant heads to atomic variables by
    combining the two 32 bit values that make up the grant head into a
    single 64 bit variable. Provide wrapper functions to combine and
    split the grant heads appropriately for calculations and use them as
    necessary.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

20 Dec, 2010

2 commits

  • We now have two copies of AIL insert operations that are mostly
    duplicate functionality. The single log item updates can be
    implemented via the bulk updates by turning xfs_trans_ail_update()
    into a simple wrapper. This removes all the duplicate insert
    functionality and associated helpers.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     
  • EFI/EFD interactions are protected from races by the AIL lock. They
    are the only type of log items that require the the AIL lock to
    serialise internal state, so they need to be separated from the AIL
    lock before we can do bulk insert operations on the AIL.

    To acheive this, convert the counter of the number of extents in the
    EFI to an atomic so it can be safely manipulated by EFD processing
    without locks. Also, convert the EFI state flag manipulations to use
    atomic bit operations so no locks are needed to record state
    changes. Finally, use the state bits to determine when it is safe to
    free the EFI and clean up the code to do this neatly.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

17 Dec, 2010

4 commits


03 Dec, 2010

1 commit

  • log->l_last_sync_lsn is updated in only one critical spot - log
    buffer Io completion - and is protected by the grant lock here. This
    requires the grant lock to be taken for every log buffer IO
    completion. Converting the l_last_sync_lsn variable to an atomic64_t
    means that we do not need to take the grant lock in log buffer IO
    completion to update it.

    This also removes the need for explicitly holding a spinlock to read
    the l_last_sync_lsn on 32 bit platforms.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

19 Oct, 2010

3 commits

  • Stop having two different names for many buffer functions and use
    the more descriptive xfs_buf_* names directly.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Alex Elder

    Christoph Hellwig
     
  • Each buffer contains both a buftarg pointer and a mount pointer. If
    we add a mount pointer into the buftarg, we can avoid needing the
    b_mount field in every buffer and grab it from the buftarg when
    needed instead. This shrinks the xfs_buf by 8 bytes.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Alex Elder

    Dave Chinner
     
  • xfs_buf_get_nodaddr() is really used to allocate a buffer that is
    uncached. While it is not directly assigned a disk address, the fact
    that they are not cached is a more important distinction. With the
    upcoming uncached buffer read primitive, we should be consistent
    with this disctinction.

    While there, make page allocation in xfs_buf_get_nodaddr() safe
    against memory reclaim re-entrancy into the filesystem by allowing
    a flags parameter to be passed.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Alex Elder

    Dave Chinner
     

27 Jul, 2010

3 commits


24 Jun, 2010

1 commit

  • The block number comes from bulkstat based inode lookups to shortcut
    the mapping calculations. We ar enot able to trust anything from
    bulkstat, so drop the block number as well so that the correct
    lookups and mappings are always done.

    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig

    Dave Chinner
     

29 May, 2010

1 commit