Bug 93021

Summary:	Mounted subvolumes can be deleted
Product:	File System	Reporter:	Timo Kokkonen (timo.kokkonen)
Component:	btrfs	Assignee:	Josef Bacik (josef)
Status:	REOPENED ---
Severity:	high	CC:	dsterba, raphael.linuxbugs, szg00000
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	v3.19	Subsystem:
Regression:	Yes	Bisected commit-id:

Description Timo Kokkonen 2015-02-10 07:44:40 UTC

Steps to reproduce:

0) Default subvolume is left its default, eg. it is /

1) Create an empty subvolume and place a root file system under it

2) Boot with kernel command line such as: root=/dev/mmcblk0p3 rw rootwait rootflags=subvol=/623

3) Mount the root subvolume eg. with: "mount /dev/mmcblk0p3 /mnt" so that the subvolume 632 becomes accessible for example snapshotting.

4) Try to delete the subvolume called 623 (the only subvolume in addition to root subvolume, the one where we are running the root file system)

Obviously we should fail here, but we don't. From this point on, we no longer have the subvolume where the root file system is located. And we are no longer able to read directory listing from / directory (which now points to the subvolume that does not exist any more), but at least some shell commands appear to be still working for a while, at least those that have working directory held open somewhere else than at /. Everything appears to be working normally except that the root directory is suddenly deleted.

I don't think this was possible until 3.19. I have been triggering this with my scripts many times by now since we started using 3.19, never had any issues with previous kernel versions.

Comment 1 Timo Kokkonen 2015-03-26 06:46:24 UTC

Still reproducible with 4.0-rc4

Comment 2 Timo Kokkonen 2015-05-27 06:11:02 UTC

It appears this is no longer reproducible with 4.1-rc4. So I'll mark this as resolved.

Comment 3 David Sterba 2015-05-27 09:53:33 UTC

Strange, I don't see any patch in btrfs that could fix that.

http://article.gmane.org/gmane.linux.kernel/1920175 from Omar is not merged. AFAIK this series http://thread.gmane.org/gmane.comp.file-systems.btrfs/45237 will fix that, but it's scheduled for 4.2 .

Comment 4 Timo Kokkonen 2015-05-27 09:59:43 UTC

You are right. I see I had accidentally left Omar Sandoval's previous fix proposal on my tree and buried it with a merge. So that's why it didn't reproduce any more for me.

I'm reopening this bug so it reflects the current state. Sorry about the noise.

Comment 5 Raphaël Jakse 2018-09-07 08:19:44 UTC

Hello,

I just ran into this issue on Linux 4.17.8 and btrfs-progs v4.16.1.

btrfs subvolume delete @ is like rm -rf / on steroids, featuring "ls: command not found" and "Oh, well." way more efficiently.

A big advantage is, this "Why does this command takes several seconds to return? Oh f*" moment does not happen, and no scaring endless file listing is shown.