All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Kaiwen Hu <kevinhu@synology.com>
Cc: quwenruo.btrfs@gmx.com, linux-btrfs@vger.kernel.org,
	dsterba@suse.cz, robbieko@synology.com, cccheng@synology.com,
	seanding@synology.com
Subject: Re: [PATCH v2] btrfs: prevent subvol with swapfile from being deleted
Date: Wed, 23 Mar 2022 13:37:54 +0000	[thread overview]
Message-ID: <YjsisrHNWoRyyfCu@debian9.Home> (raw)
In-Reply-To: <20220323071031.1398152-1-kevinhu@synology.com>

On Wed, Mar 23, 2022 at 03:10:32PM +0800, Kaiwen Hu wrote:
> This patch prevent subvol being deleted when the subvol contains
> any active swapfile.
> 
> Since the subvolume is deleted, we cannot swapoff the swapfile in
> this deleted subvolume.  However, the swapfile is still active,
> we unable to unmount this volume.  Let it into some deadlock
> situation.
> 
> 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.
> 
> Reviewed-by: Robbie Ko <robbieko@synology.com>
> Signed-off-by: Kaiwen Hu <kevinhu@synology.com>

Looks good.

Reviewed-by: Filipe Manana <fdmanana@suse.com>

Are you planning on sending in a test case for fstests as well?
It's great to have a reproducer in a changelog, but unless it is
turned into a test case for fstests, it doesn't prevent a regression
in the future.

Thanks.

> ---
> 
> Add comment on it.
> 
>  fs/btrfs/inode.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 5bbea5ec31fc..b32def311f44 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -4460,6 +4460,12 @@ int btrfs_delete_subvolume(struct inode *dir, struct dentry *dentry)
>  			   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 with active swapfile");
> +		return -ETXTBSY;
> +	}
>  	root_flags = btrfs_root_flags(&dest->root_item);
>  	btrfs_set_root_flags(&dest->root_item,
>  			     root_flags | BTRFS_ROOT_SUBVOL_DEAD);
> @@ -10418,8 +10424,22 @@ static int btrfs_swap_activate(struct swap_info_struct *sis, struct file *file,
>  	 * 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
> +	 * remove yet. To prevent this race, we check the root's mark before
> +	 * activating 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 is marked for deletion");
> +		return -EINVAL;
> +	}
>  	atomic_inc(&root->nr_swapfiles);
> +	spin_unlock(&root->root_item_lock);
> +
>  
>  	isize = ALIGN_DOWN(inode->i_size, fs_info->sectorsize);
>  
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2022-03-23 13:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 10:27 [PATCH] btrfs: prevent subvol with swapfile from being deleted Kaiwen Hu
2022-03-22 10:47 ` Qu Wenruo
2022-03-22 19:39   ` David Sterba
2022-03-23  3:13     ` Kaiwen Hu
2022-03-23  4:40       ` Qu Wenruo
2022-03-23  7:10         ` [PATCH v2] " Kaiwen Hu
2022-03-23  7:59           ` Qu Wenruo
2022-03-23 12:34           ` David Sterba
2022-03-23 13:33             ` Filipe Manana
2022-03-23 13:37           ` Filipe Manana [this message]
2022-03-23 21:45           ` David Sterba
2022-03-24  4:59             ` Kaiwen Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YjsisrHNWoRyyfCu@debian9.Home \
    --to=fdmanana@kernel.org \
    --cc=cccheng@synology.com \
    --cc=dsterba@suse.cz \
    --cc=kevinhu@synology.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=robbieko@synology.com \
    --cc=seanding@synology.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.