From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 3/4] xfs: xfs_remove deadlocks due to inverted AGF vs AGI lock ordering
Date: Mon, 30 Sep 2013 17:14:49 -0500 [thread overview]
Message-ID: <20130930221449.GP1935@sgi.com> (raw)
In-Reply-To: <1380497826-13474-4-git-send-email-david@fromorbit.com>
Hi Dave,
On Mon, Sep 30, 2013 at 09:37:05AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Removing an inode from the namespace involves removing the directory
> entry and dropping the link count on the inode. Removing the
> directory entry can result in locking an AGF (directory blocks were
> freed) and removing a link count can result in placing the inode on
> an unlinked list which results in locking an AGI.
>
> The big problem here is that we have an ordering constraint on AGF
> and AGI locking - inode allocation locks the AGI, then can allocate
> a new extent for new inodes, locking the AGF after the AGI.
> Similarly, freeing the inode removes the inode from the unlinked
> list, requiring that we lock the AGI first, and then freeing the
> inode can result in an inode chunk being freed and hence freeing
> disk space requiring that we lock an AGF.
>
> Hence the ordering that is imposed by other parts of the code is AGI
> before AGF. This means we cannot remove the directory entry before
> we drop the inode reference count and put it on the unlinked list as
> this results in a lock order of AGF then AGI, and this can deadlock
> against inode allocation and freeing. Therefore we must drop the
> link counts before we remove the directory entry.
>
> This is still safe from a transactional point of view - it is not
> until we get to xfs_bmap_finish() that we have the possibility of
> multiple transactions in this operation. Hence as long as we remove
> the directory entry and drop the link count in the first transaction
> of the remove operation, there are no transactional constraints on
> the ordering here.
>
> Change the ordering of the operations in the xfs_remove() function
> to align the ordering of AGI and AGF locking to match that of the
> rest of the code.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Hmmm.. I'm not quite comfortable with this one yet... It'll probably be
better after some more review. Did you happen to have a test case to go with
this?
Thanks,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-09-30 22:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-29 23:37 [PATCH 0/4] xfs: candidate fixes for 3.12-rc4 Dave Chinner
2013-09-29 23:37 ` [PATCH 1/4] xfs: lockdep needs to know about 3 dquot-deep nesting Dave Chinner
2013-09-30 21:19 ` Ben Myers
2013-09-29 23:37 ` [PATCH 2/4] xfs: dirent dtype presence is dependent on directory magic numbers Dave Chinner
2013-09-30 22:02 ` Ben Myers
2013-10-18 16:56 ` Rich Johnston
2013-10-18 22:30 ` Dave Chinner
2013-10-18 22:41 ` Rich Johnston
2013-09-29 23:37 ` [PATCH 3/4] xfs: xfs_remove deadlocks due to inverted AGF vs AGI lock ordering Dave Chinner
2013-09-30 22:14 ` Ben Myers [this message]
2013-10-01 10:57 ` Dave Chinner
2013-09-29 23:37 ` [PATCH 4/4] xfs: open code inc_inode_iversion when logging an inode Dave Chinner
2013-09-30 22:24 ` Eric Sandeen
2013-09-30 22:39 ` Ben Myers
2013-10-01 11:12 ` Dave Chinner
2013-10-01 23:04 ` Ben Myers
2013-09-30 22:52 ` [PATCH 0/4] xfs: candidate fixes for 3.12-rc4 Ben Myers
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=20130930221449.GP1935@sgi.com \
--to=bpm@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.