Btrfs: setup inode location during btrfs_init_inode_locked
authorChris Mason <clm@fb.com>
Fri, 10 Jan 2014 01:28:00 +0000 (17:28 -0800)
committerBen Hutchings <ben@decadent.org.uk>
Tue, 1 Apr 2014 23:58:45 +0000 (00:58 +0100)
commit5da1d4795ac0f31770429557c3d6003fe5c7641c
treea7addae37d223e0a2cec8f0309b6a3a406538620
parent1d4b777fc535b6f1c44aee2f2c77ac236d7336c6
Btrfs: setup inode location during btrfs_init_inode_locked

commit 90d3e592e99b8e374ead2b45148abf506493a959 upstream.

We have a race during inode init because the BTRFS_I(inode)->location is setup
after the inode hash table lock is dropped.  btrfs_find_actor uses the location
field, so our search might not find an existing inode in the hash table if we
race with the inode init code.

This commit changes things to setup the location field sooner.  Also the find actor now
uses only the location objectid to match inodes.  For inode hashing, we just
need a unique and stable test, it doesn't have to reflect the inode numbers we
show to userland.

Signed-off-by: Chris Mason <clm@fb.com>
[bwh: Backported to 3.2:
 - No hashval in btrfs_iget_locked()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
fs/btrfs/inode.c