From: Brian Foster <bfoster@redhat.com>
To: xfs@oss.sgi.com
Subject: [PATCH v2] xfs: don't truncate attribute extents if no extents exist
Date: Mon, 22 Jun 2015 09:38:50 -0400 [thread overview]
Message-ID: <1434980330-45272-1-git-send-email-bfoster@redhat.com> (raw)
In-Reply-To: <1434631741-50856-2-git-send-email-bfoster@redhat.com>
The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that
attribute blocks exist to invalidate. It is possible to have an
attribute fork without extents, however. Consider the case where the
attribute fork is created towards the beginning of xfs_attr_set() but
some part of the subsequent attribute set fails.
If an inode in such a state hits xfs_attr_inactive(), it eventually
calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a
filesystem corruption warning, returns an error that bubbles back up to
xfs_attr_inactive(), and leads to destruction of the in-core attribute
fork without an on-disk reset. If the inode happens to make it back
through xfs_inactive() in this state (e.g., via a concurrent bulkstat
that cycles the inode from the reclaim state and releases it), i_afp
might not exist when xfs_bmapi_read() is called and causes a NULL
dereference panic.
A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB)
reproduces these problems. The behavior is a regression caused by:
6dfe5a0 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind
... which removed logic that avoided the attribute extent truncate when
no extents exist. Restore this logic to ensure the attribute fork is
destroyed and reset correctly if it exists without any allocated
extents.
Signed-off-by: Brian Foster <bfoster@redhat.com>
---
Here's v2 of the attr inactive fix with the additional comment requested
by Christoph. After beating my head against reproducing this with
xfstests a bit last week, I determined that selinux was a contributing
factor in my original fsstress reproducer. I found a
non-selinux/fsstress reproducer sequence, so I'll cook up an xfstest
based on that soon...
Brian
v2:
- Added comment to explain logic behind skipping the inval/truncate in
the no attribute case.
v1: http://oss.sgi.com/archives/xfs/2015-06/msg00276.html
fs/xfs/xfs_attr_inactive.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/xfs/xfs_attr_inactive.c b/fs/xfs/xfs_attr_inactive.c
index 69a154c..2bb959a 100644
--- a/fs/xfs/xfs_attr_inactive.c
+++ b/fs/xfs/xfs_attr_inactive.c
@@ -433,8 +433,14 @@ xfs_attr_inactive(
*/
xfs_trans_ijoin(trans, dp, 0);
- /* invalidate and truncate the attribute fork extents */
- if (dp->i_d.di_aformat != XFS_DINODE_FMT_LOCAL) {
+ /*
+ * Invalidate and truncate the attribute fork extents. Make sure the
+ * fork actually has attributes as otherwise the invalidation has no
+ * blocks to read and returns an error. In this case, just do the fork
+ * removal below.
+ */
+ if (xfs_inode_hasattr(dp) &&
+ dp->i_d.di_aformat != XFS_DINODE_FMT_LOCAL) {
error = xfs_attr3_root_inactive(&trans, dp);
if (error)
goto out_cancel;
--
1.9.3
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-06-22 13:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 12:48 [PATCH 0/2] xfs: misc. attribute and log recovery fixes Brian Foster
2015-06-18 12:49 ` [PATCH 1/2] xfs: don't truncate attribute extents if no extents exist Brian Foster
2015-06-19 15:14 ` Christoph Hellwig
2015-06-19 15:45 ` Brian Foster
2015-06-21 9:22 ` Christoph Hellwig
2015-06-22 13:38 ` Brian Foster [this message]
2015-06-18 12:49 ` [PATCH 2/2] xfs: validate transaction header length on log recovery Brian Foster
2015-06-21 9:27 ` Christoph Hellwig
2015-06-21 20:25 ` Brian Foster
2015-06-21 23:05 ` Dave Chinner
2015-06-22 13:59 ` Brian Foster
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=1434980330-45272-1-git-send-email-bfoster@redhat.com \
--to=bfoster@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox