• Jeff Mahoney's avatar
    btrfs: fix race with relocation recovery and fs_root setup · a9b3311e
    Jeff Mahoney authored
    If we have to recover relocation during mount, we'll ultimately have to
    evict the orphan inode.  That goes through the reservation dance, where
    priority_reclaim_metadata_space and flush_space expect fs_info->fs_root
    to be valid.  That's the next thing to be set up during mount, so we
    crash, almost always in flush_space trying to join the transaction
    but priority_reclaim_metadata_space is possible as well.  This call
    path has been problematic in the past WRT whether ->fs_root is valid
    yet.  Commit 957780eb (Btrfs: introduce ticketed enospc
    infrastructure) added new users that are called in the direct path
    instead of the async path that had already been worked around.
    
    The thing is that we don't actually need the fs_root, specifically, for
    anything.  We either use it to determine whether the root is the
    chunk_root for use in choosing an allocation profile or as a root to pass
    btrfs_join_transaction before immediately committing it.  Anything that
    isn't the chunk root works in the former case and any root works in
    the latter.
    
    A simple fix is to use a root we know will always be there: the
    extent_root.
    
    Cc: <stable@vger.kernel.org> # v4.8+
    Fixes: 957780eb (Btrfs: introduce ticketed enospc infrastructure)
    Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
    Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    a9b3311e
extent-tree.c 299 KB