Btrfs: fix releasepage to avoid unlocking extents we haven't locked
authorChris Mason <chris.mason@oracle.com>
Thu, 24 Sep 2009 00:28:46 +0000 (20:28 -0400)
committerChris Mason <chris.mason@oracle.com>
Thu, 24 Sep 2009 00:30:53 +0000 (20:30 -0400)
During releasepage, we try to drop any extent_state structs for the
bye offsets of the page we're releaseing.  But the code was incorrectly
telling clear_extent_bit to delete the state struct unconditionallly.

Normally this would be fine because we have the page locked, but other
parts of btrfs will lock down an entire extent, the most common place
being IO completion.

releasepage was deleting the extent state without first locking the extent,
which may result in removing a state struct that another process had
locked down.  The fix here is to leave the NODATASUM and EXTENT_LOCKED
bits alone in releasepage.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
fs/btrfs/extent_io.c

index dcce98d0ec4f85e901e7c5de18d907b702eee1b9..0cb88f8146ea85efa5bc944c9d95995a3d0ad772 100644 (file)
@@ -2809,8 +2809,13 @@ int try_release_extent_state(struct extent_map_tree *map,
        else {
                if ((mask & GFP_NOFS) == GFP_NOFS)
                        mask = GFP_NOFS;
-               clear_extent_bit(tree, start, end, EXTENT_UPTODATE,
-                                1, 1, NULL, mask);
+               /*
+                * at this point we can safely clear everything except the
+                * locked bit and the nodatasum bit
+                */
+               clear_extent_bit(tree, start, end,
+                                ~(EXTENT_LOCKED | EXTENT_NODATASUM),
+                                0, 0, NULL, mask);
        }
        return ret;
 }