From: Alex Elder <aelder@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/6] xfs: introduce inode cluster buffer trylocks for xfs_iflush
Date: Fri, 25 Mar 2011 16:00:50 -0500 [thread overview]
Message-ID: <1301086850.2537.681.camel@doink> (raw)
In-Reply-To: <1300860870-15471-4-git-send-email-david@fromorbit.com>
On Wed, 2011-03-23 at 17:14 +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> There is an ABBA deadlock between synchronous inode flushing in
> xfs_reclaim_inode and xfs_icluster_free. xfs_icluster_free locks the
> buffer, then takes inode ilocks, whilst synchronous reclaim takes
> the ilock followed by the buffer lock in xfs_iflush().
>
> To avoid this deadlock, separate the inode cluster buffer locking
> semantics from the synchronous inode flush semantics, allowing
> callers to attempt to lock the buffer but still issue synchronous IO
> if it can get the buffer. This requires xfs_iflush() calls that
> currently use non-blocking semantics to pass SYNC_TRYLOCK rather
> than 0 as the flags parameter.
>
> This allows xfs_reclaim_inode to avoid the deadlock on the buffer
> lock and detect the failure so that it can drop the inode ilock and
> restart the reclaim attempt on the inode. This allows
> xfs_ifree_cluster to obtain the inode lock, mark the inode stale and
> release it and hence defuse the deadlock situation. It also has the
> pleasant side effect of avoiding IO in xfs_reclaim_inode when it
> tries to next reclaim the inode as it is now marked stale.
Looks good.
Reviewed-by: Alex Elder <aelder@sgi.com>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-03-25 20:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 6:14 xfs: outstanding patches for 2.6.39 Dave Chinner
2011-03-23 6:14 ` [PATCH 1/6] xfs: preallocation transactions do not need to be synchronous Dave Chinner
2011-03-24 17:18 ` brian.foster
2011-03-24 22:53 ` [PATCH V2] " Dave Chinner
2011-03-25 21:00 ` [PATCH 1/6] " Alex Elder
2011-03-25 22:02 ` Dave Chinner
2011-03-23 6:14 ` [PATCH 2/6] vmap: flush vmap aliases when mapping fails Dave Chinner
2011-03-25 21:00 ` Alex Elder
2011-03-23 6:14 ` [PATCH 3/6] xfs: introduce inode cluster buffer trylocks for xfs_iflush Dave Chinner
2011-03-25 21:00 ` Alex Elder [this message]
2011-03-23 6:14 ` [PATCH 4/6] xfs: xfs_trans_read_buf() should return an error on failure Dave Chinner
2011-03-23 11:53 ` Christoph Hellwig
2011-03-25 21:01 ` Alex Elder
2011-03-23 6:14 ` [PATCH 5/6] xfs: register the inode cache shrinker before quotachecks Dave Chinner
2011-03-23 21:24 ` Arkadiusz Miskiewicz
2011-03-25 12:56 ` Michael Weissenbacher
2011-03-25 23:08 ` Dave Chinner
2011-03-25 21:01 ` Alex Elder
2011-03-23 6:14 ` [PATCH 6/6] xfs: stop using the page cache to back the buffer cache Dave Chinner
2011-03-25 21:02 ` Alex Elder
2011-03-25 22:04 ` Dave Chinner
2011-03-23 7:01 ` xfs: outstanding patches for 2.6.39 Andi Kleen
2011-03-23 11:38 ` Dave Chinner
2011-03-23 16:05 ` Andi Kleen
2011-03-23 22:48 ` Dave Chinner
2011-03-23 11:18 ` Christoph Hellwig
2011-03-23 11:38 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301086850.2537.681.camel@doink \
--to=aelder@sgi.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.