]> git.neil.brown.name Git - history.git/commit
[PATCH] ext2/3: incorrect increment of i_blocks when keeping the same xattr block
authorAndrew Morton <akpm@osdl.org>
Fri, 6 Feb 2004 00:50:15 +0000 (16:50 -0800)
committerGreg Kroah-Hartman <greg@kroah.com>
Fri, 6 Feb 2004 00:50:15 +0000 (16:50 -0800)
commit1448491581e6b28b5e607fbe78207e3bdac779b6
tree2aa4d7ee03677c34ef14201b279518a675cb7861
parent389f24aa525f2fd0d386858bfaa5d46c5a7c6a3f
[PATCH] ext2/3: incorrect increment of i_blocks when keeping the same xattr block

From: Andreas Gruenbacher <agruen@suse.de>

Here is a fix for extended attributes on ext2 and ext3, reported by
Stephen Tweedie <sct@redhat.com>.

From: Stephen Tweedie <sct@redhat.com>:

When you have an EA block that is shared between multiple inodes; AND you
then change an attribute in that on one inode, AND the new attribute value
is the same as the old, then xattr computes the new EA block, finds it
still in the cache, bumps the reference count on it (and the i_blocks field
on the inode, incidentally), and leaves it incremented because we haven't
changed EA block so there's no need to drop the refcount on the old block.

So *every* time you have more than one inode sharing an EA block and you
perform an identical write to an EA, you get a leak on both i_blocks and
the EA refcount.

This is a big problem for symlinks, which rely on correct i_blocks
accounting to determine the difference between fast and slow symlinks.
With the leak, you end up thinking that a fast symlink (ie.  one small
enough to be stored in the inode direct blocks) is slow, so you dereference
the ascii contents of the symlink as if they were a disk block address.
That typically results in EIO all over the place.
fs/ext2/xattr.c
fs/ext3/xattr.c