Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp50944lfv; Tue, 12 Apr 2022 16:54:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNHEwZWZVMdXQiDFNyMwR2R9H/LslEfoAf+HTlz13eowQoeOWQkIiFe/IjErEjq6pImqOL X-Received: by 2002:a05:6a00:2450:b0:4f7:bf07:c063 with SMTP id d16-20020a056a00245000b004f7bf07c063mr40203707pfj.51.1649807671009; Tue, 12 Apr 2022 16:54:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649807671; cv=none; d=google.com; s=arc-20160816; b=QqRwx/bx5g/fnAOILWsqvSKDy3gwq4O5S4er0OASVbYCXyC+u37T1xk+xo/akESNER wLqf4OE3Dk8zMK4jo6ijSlSJvCVf06eKBN3ix/79+TftUU7uW01gNrLuC4iB2hVks3dJ k/D0UKrbn8qbg6s2Wkag8rFmVilRfQfrX7bJ3UjshHQjYAJf8oMtGQJSk1O12QANGVaA NZhKyOHLbFwpZTYtmzLlw/Nnx8Lh/59l7LhpmIzT8Kt4pv8R36Oepa5NNJIK1701W42r /lz8vwoKi2jBXI+iUSkAc2ZzgFbe59pwm4c0qhZQttXxZr/DX1HoJKGJ9uRf3+cO6v34 UE/w== 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=1mnFEobhWlzwPJWLtCEuCB09X8N3Ug+h3vZGl6U39Fs=; b=JUAl5q/rCP6dLsKKTInHBjfCLBLcNEbu6hpbI9sVIy9esz94fzL8PHqt2MboYIjX+I /RYm+OjcmHorvd/ln9uJZArJHzeS0yBDYEdkBOv5VMEWQFrmJlIT2lWAfxS1ZmI4b5xo VPLBZp61T+0irY8M/7cTNNL3QbwxXV45sztijRFdHmtpKTWnoD0Kz4q3e17Z2jtjaPMW 84lHM7IWc/58o9KrYHqGGjTEhlVRYRW34wDxpB8TYYj6+6OTaHPRZP+1Padvf02SPUT1 H9R1/YIVvSUUSJQ91wDN3vCsXo19R83eQBHefPzyV+X7dJMaUhR2QaUiL25j8VVnyaC1 tnsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Xe8Z/L13"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id g15-20020a170902868f00b00153b2d164bcsi12518500plo.196.2022.04.12.16.54.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 16:54:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Xe8Z/L13"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 DB3917CDCC; Tue, 12 Apr 2022 14:49:14 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380628AbiDLIWa (ORCPT + 99 others); Tue, 12 Apr 2022 04:22:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353806AbiDLHZz (ORCPT ); Tue, 12 Apr 2022 03:25:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77C0F9FD8; Tue, 12 Apr 2022 00:04:41 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 1766C60B65; Tue, 12 Apr 2022 07:04:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 209CEC385A1; Tue, 12 Apr 2022 07:04:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649747080; bh=3URoS/TUJZ3MsAy6YxJ1sR6pRPkgsVOwX30cNz/8tWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xe8Z/L13oCYhAToa/YttnnlDsRG8ATbUnKdmgLv5Evrr92DZnbN2uXDwiN/3q3JAs cNl6Wn0ybSYMLp1LhpId1WYn8OWyhZbBs2famfp4nHZQlgO/3c79WICUg5kgWsAKP5 6jvdGOVOzjYjqoiAWU38MwYYPh+njb0/sx78MBtc= 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.16 235/285] btrfs: prevent subvol with swapfile from being deleted Date: Tue, 12 Apr 2022 08:31:32 +0200 Message-Id: <20220412062950.444603043@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220412062943.670770901@linuxfoundation.org> References: <20220412062943.670770901@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 @@ -4462,6 +4462,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); @@ -10764,8 +10771,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);