]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
ext4: fix ext4_free_inode() vs. ext4_claim_inode() race
authorEric Sandeen <sandeen@redhat.com>
Tue, 2 Jun 2009 12:09:13 +0000 (08:09 -0400)
committerGreg Kroah-Hartman <gregkh@suse.de>
Fri, 12 Jun 2009 03:01:37 +0000 (20:01 -0700)
commitfccb0272b539368be564a8d09ae4b71134a237d3
tree63409a25ce867dfe130c17f234606402c6f1fafc
parent00d025abdfdcc686052ed1d9c25f10ead680e620
ext4: fix ext4_free_inode() vs. ext4_claim_inode() race

(cherry picked from commit 7ce9d5d1f3c8736511daa413c64985a05b2feee3)

I was seeing fsck errors on inode bitmaps after a 4 thread
dbench run on a 4 cpu machine:

Inode bitmap differences: -50736 -(50752--50753) etc...

I believe that this is because ext4_free_inode() uses atomic
bitops, and although ext4_new_inode() *used* to also use atomic
bitops for synchronization, commit
393418676a7602e1d7d3f6e560159c65c8cbd50e changed this to use
the sb_bgl_lock, so that we could also synchronize against
read_inode_bitmap and initialization of uninit inode tables.

However, that change left ext4_free_inode using atomic bitops,
which I think leaves no synchronization between setting &
unsetting bits in the inode table.

The below patch fixes it for me, although I wonder if we're
getting at all heavy-handed with this spinlock...

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/ext4/ialloc.c