• Jeff Mahoney's avatar
    btrfs: defer adding raid type kobject until after chunk relocation · 75cb379d
    Jeff Mahoney authored
    Any time the first block group of a new type is created, we add a new
    kobject to sysfs to hold the attributes for that type.  Kobject-internal
    allocations always use GFP_KERNEL, making them prone to fs-reclaim races.
    While it appears as if this can occur any time a block group is created,
    the only times the first block group of a new type can be created in
    memory is at mount and when we create the first new block group during
    raid conversion.
    
    This patch adds a new list to track pending kobject additions and then
    handles them after we do chunk relocation.  Between relocating the
    target chunk (or forcing allocation of a new chunk in the case of data)
    and removing the old chunk, we're in a safe place for fs-reclaim to
    occur.  We're holding the volume mutex, which is already held across
    page faults, and the delete_unused_bgs_mutex, which will only stall
    the cleaner thread.
    Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
    Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    75cb379d
volumes.c 195 KB