Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp34126pxb; Tue, 12 Apr 2022 16:03:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcg9S7D0pulS2UVH99vvUmFtS3/p83WEe3poiP454y/ViWRjGqkpR7HwgwAIbbW8sQBz65 X-Received: by 2002:a17:902:edc5:b0:158:4065:a5ce with SMTP id q5-20020a170902edc500b001584065a5cemr17817848plk.55.1649804594872; Tue, 12 Apr 2022 16:03:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649804594; cv=none; d=google.com; s=arc-20160816; b=Gmr8MzjfaZe16xYU4E9abChGZKL0lc9SaBhwyCEuowUc/c2Q7JcuS8bhfk/vD5m5No u7Jm/+qHEBesAy7Gg27JWfmmEMQXC5m29m88KhwG1z8qgCxyTfBFLe97zz56Yt2OWrHW 7B7gb5ZshTI4pnjbFbi1SfxY5ks1HPiUT3XeCm2/ok2ren/SMU2oxlG4X9UzLx22UYN3 97+x4uZNaEQXKrcclh3NZ+bNLFgF9T++hJ9ZztPN54S9tr4izouZTBt+pzb8UNecy5C6 /F1jwaZ5RlPP8UrN4yIQBNayl28IdAtmC0VEwpBQ4ULeTIMUcW2e2hz96MAowYhjNL0i VN5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=F0awmI7s843pKGC37lYQms6FoOjefqEJ0duWFWngnP0=; b=AKSWT45oagTGLmZEArQsuJlw6M6E1D2HFV9Fwl6R265Ge2ReSGoCDdplI2Fi1S8569 ZRomLQrxQqrsitlRlK+DLyXgixVH149KZ48WsGs0qE5VUfx1HX7+AzcHBp8iUl0CdOHp TVzNeLfcgJLunPrVC+ltL+2NF44pNmlqM7kciQAi28CfYIMYLOKiII+kLMYCxkTHYHi8 4TvwxVylV8GkUW8Kr3m4M62EnpAodnoHhqPzQKiT2mjrqaVzaJ1YJW8u2JETcX24u5xC 09WsVnMhb3XglCAZL7nI9f8ElBNgSuEoax5btI46VBo7rUedbl4/NYJN4AccFYbsKEGo P9MQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Sk1EyDF1; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h37-20020a635325000000b00399322e8862si3923723pgb.380.2022.04.12.16.03.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:03:14 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Sk1EyDF1; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9FB411E7A53; Tue, 12 Apr 2022 14:45:31 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351026AbiDLG5G (ORCPT + 99 others); Tue, 12 Apr 2022 02:57:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350624AbiDLGuF (ORCPT ); Tue, 12 Apr 2022 02:50:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4066D27CEB; Mon, 11 Apr 2022 23:39:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 38476B81B40; Tue, 12 Apr 2022 06:39:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A88FEC385AC; Tue, 12 Apr 2022 06:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649745583; bh=o/sM6v6M4Sew2tuYep2bzHUM3679jckNvT+mDdQpves=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sk1EyDF1OnV9ZF+dMEeFvIBvdTGo8Sv6H+OJfIkmrGrlc72zkavj9myGIzrJorCmP yLmQU+/YLa1pRaQSDV1rvtZRZ5EZ8qtk4pUmS2UgoRkzMfhGt7Uydw9HqodaaAti45 bB6NDe5HIblppB5KPie0++qBz9OO5tXvtMySkTXg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robbie Ko , Qu Wenruo , Filipe Manana , Kaiwen Hu , David Sterba Subject: [PATCH 5.10 145/171] btrfs: prevent subvol with swapfile from being deleted Date: Tue, 12 Apr 2022 08:30:36 +0200 Message-Id: <20220412062932.087459050@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412062927.870347203@linuxfoundation.org> References: <20220412062927.870347203@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Kaiwen Hu commit 60021bd754c6ca0addc6817994f20290a321d8d6 upstream. A subvolume with an active swapfile must not be deleted otherwise it would not be possible to deactivate it. After the subvolume is deleted, we cannot swapoff the swapfile in this deleted subvolume because the path is unreachable. The swapfile is still active and holding references, the filesystem cannot be unmounted. The test looks like this: mkfs.btrfs -f $dev > /dev/null mount $dev $mnt btrfs sub create $mnt/subvol touch $mnt/subvol/swapfile chmod 600 $mnt/subvol/swapfile chattr +C $mnt/subvol/swapfile dd if=/dev/zero of=$mnt/subvol/swapfile bs=1K count=4096 mkswap $mnt/subvol/swapfile swapon $mnt/subvol/swapfile btrfs sub delete $mnt/subvol swapoff $mnt/subvol/swapfile # failed: No such file or directory swapoff --all unmount $mnt # target is busy. To prevent above issue, we simply check that whether the subvolume contains any active swapfile, and stop the deleting process. This behavior is like snapshot ioctl dealing with a swapfile. CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Robbie Ko Reviewed-by: Qu Wenruo Reviewed-by: Filipe Manana Signed-off-by: Kaiwen Hu Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/inode.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4023,6 +4023,13 @@ int btrfs_delete_subvolume(struct inode dest->root_key.objectid); return -EPERM; } + if (atomic_read(&dest->nr_swapfiles)) { + spin_unlock(&dest->root_item_lock); + btrfs_warn(fs_info, + "attempt to delete subvolume %llu with active swapfile", + root->root_key.objectid); + return -EPERM; + } root_flags = btrfs_root_flags(&dest->root_item); btrfs_set_root_flags(&dest->root_item, root_flags | BTRFS_ROOT_SUBVOL_DEAD); @@ -10215,8 +10222,23 @@ static int btrfs_swap_activate(struct sw * set. We use this counter to prevent snapshots. We must increment it * before walking the extents because we don't want a concurrent * snapshot to run after we've already checked the extents. - */ + * + * It is possible that subvolume is marked for deletion but still not + * removed yet. To prevent this race, we check the root status before + * activating the swapfile. + */ + spin_lock(&root->root_item_lock); + if (btrfs_root_dead(root)) { + spin_unlock(&root->root_item_lock); + + btrfs_exclop_finish(fs_info); + btrfs_warn(fs_info, + "cannot activate swapfile because subvolume %llu is being deleted", + root->root_key.objectid); + return -EPERM; + } atomic_inc(&root->nr_swapfiles); + spin_unlock(&root->root_item_lock); isize = ALIGN_DOWN(inode->i_size, fs_info->sectorsize);