2010-04-13 19:39:52

by Jeff Mahoney

[permalink] [raw]
Subject: [PATCH] reiserfs: Fix corruption during shrinking of xattrs

Commit 48b32a3553a54740d236b79a90f20147a25875e3 introduced a problem
that causes corruption when extended attributes are replaced with a
smaller value.

The issue is that the reiserfs_setattr to shrink the xattr file was
moved from before the write to after the write.

The root issue has always been in the reiserfs xattr code, but was
papered over by the fact that in the shrink case, the file would just
be expanded again while the xattr was written.

The end result is that the last 8 bytes of xattr data are lost.

This patch fixes it to use new_size.

This issue was reported at: https://bugzilla.kernel.org/show_bug.cgi?id=14826

Signed-off-by: Jeff Mahoney <[email protected]>
Cc: [email protected]
---

fs/reiserfs/xattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/reiserfs/xattr.c
+++ b/fs/reiserfs/xattr.c
@@ -553,7 +560,7 @@ reiserfs_xattr_set_handle(struct reiserf
if (!err && new_size < i_size_read(dentry->d_inode)) {
struct iattr newattrs = {
.ia_ctime = current_fs_time(inode->i_sb),
- .ia_size = buffer_size,
+ .ia_size = new_size,
.ia_valid = ATTR_SIZE | ATTR_CTIME,
};

--
Jeff Mahoney
SUSE Labs


2010-04-14 08:32:46

by Christian Kujau

[permalink] [raw]
Subject: Re: [PATCH] reiserfs: Fix corruption during shrinking of xattrs

On Tue, 13 Apr 2010 at 15:39, Jeff Mahoney wrote:
> This patch fixes it to use new_size.

Tested-by: Christian Kujau <[email protected]>

With this patch applied (to today's mainline git, 2.6.34-rc4) I was able
to create 30k files with xattrs on the same test system that was failing
to do so before.

Thanks for the fix!

Christian.
--
BOFH excuse #88:

Boss' kid fucked up the machine


Attachments:
reiserfs-xattr_rc4.diff (469.00 B)

2010-04-15 23:50:30

by Christian Kujau

[permalink] [raw]
Subject: Re: [PATCH] reiserfs: Fix corruption during shrinking of xattrs

On Wed, 14 Apr 2010 at 01:32, Christian Kujau wrote:
> On Tue, 13 Apr 2010 at 15:39, Jeff Mahoney wrote:
> > This patch fixes it to use new_size.
>
> Tested-by: Christian Kujau <[email protected]>

Dang. While this *does* seem to fix the "Input/output error after a large
amount of files have their xattrs removed", it does not fix the initial
issue in #14826, where occasionally this jdm-20002 message shows up.

I just tested this: I still have this calendarserver (caldavd) and it's
heavily using xattr. I have removed everything under /var/spool/caldavd,
started caldavd and am now importing a calendar. caldavd will now create
files under /var/spool/caldavd, wil assign xattrs and read them. And just
after a few operations, this happens again:

[138794.184926] REISERFS warning (device xvda3): jdm-20002
reiserfs_xattr_get: Invalid hash for xattr
(user.{http:%2F%2Ftwistedmatrix.com%2Fxml_namespace%2Fdav%2Fprivate%2F}quota-used)
associated with [765 3282 0x0 SD]

[139238.740552] REISERFS warning (device xvda3): jdm-20002
reiserfs_xattr_get: Invalid hash for xattr (user.{DAV:}displayname)
associated with [765 3402 0x0 SD]

Inodes 3282, 3402, aka

./calendars/__uids__/afebe2f1-f51a-5859-af15-f22312ad6634
./calendars/__uids__/afebe2f1-f51a-5859-af15-f22312ad6634/2CC21268-C87E-4AE6-AFD4-33946D5621AB

....under /var/spool/caldavd. So it does happen for new files
(directories in this case) indeed.

However, there's no file corruption, no I/O errors - I can still access
the directory and its contents. The xattr information might be lost
though. Bug #14826 somehow transformed into "my filesystem is corrupt", as
the bug with the large amount of files/xattr seems to generate the same
message in the syslog. But that's a different issue, methinks.

Christian.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=14826
--
BOFH excuse #124:


user to computer ration too low.