Bug 15325

Summary:	Removing external USB btrfs drive causes kernel crash
Product:	File System	Reporter:	rocko (rockorequin)
Component:	btrfs	Assignee:	fs_btrfs (fs_btrfs)
Status:	CLOSED CODE_FIX
Severity:	high	CC:	alan, rockorequin
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.33-rc8	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	syslog of btfrs kernel crash syslog of btfrs kernel crash - NULL pointer dereference log of removing external btrfs drive and re-attaching it

Description rocko 2010-02-16 07:39:14 UTC

Created attachment 25061 [details]
syslog of btfrs kernel crash

This bug hangs the kernel. I've experienced it twice now. See attached log.

Both times the crash happened after I suspended with an external btrfs drive plugged in and resumed without it. The first time the crash happened before X's screen saver password entry screen could appear, the second time around six hours after resume. The second time I could see that the system thought the external drive was still mounted after resume (ie its icon was still on the desktop).

Version info: Ubuntu 9.10, 2.6.33-rc8 amd64

Note: This might be the same as bug #15267 (which was reported against 2.6.32.5).

Comment 1 rocko 2010-02-16 23:30:18 UTC

It doesn't require a suspend/resume; simply unplugging the drive while it's mounted can cause the crash. This last time the crash upset my Intel Wireless 4965 AGN card so badly that even several cold boots back into 2.6.33-rc8 wouldn't bring it up; I had to reboot into the 2.6.32.8 kernel to fix it.

Comment 2 rocko 2010-02-17 02:58:20 UTC

Created attachment 25073 [details]
syslog of btfrs kernel crash - NULL pointer dereference

Actually the last crash due to the external drive being removed looks like something different (unable to handle kernel NULL pointer dereference at 0000000000000030) - see attached log.

Comment 3 rocko 2010-02-21 00:55:50 UTC

This is consistently reproducible, eg with a btrfs USB key. Removing the drive causes a crash due to btrfs not being able to write to it.

Could this be related to another problem with btrfs, ie that if you mount the drive on say /dev/sdb1, remove it, then mount another drive on /dev/sdb1 and reinsert the btrfs drive so it is assigned to /dev/sdc1, the system can't mount it (it tries still to mount it on /dev/sdb1 and fails to read the superblock)?

Comment 4 rocko 2010-05-15 08:31:55 UTC

In 2.6.34-rc7, removing the external drive doesn't cause a complete kernel crash but does lock up bits of the kernel: eg opening gnome-terminal and doing "sudo -s" just hangs, and the next time you open a gnome-terminal it hangs; you can't ssh into the machine; gnome-panel becomes unresponsive.

Comment 5 Alan 2012-05-14 14:59:32 UTC

Should be fixed in current kernels - the underlying block layer handling was fixed. If not please re-test with 3.3 or 3.4-rc and attach the updated failure reports

Comment 6 rocko 2012-05-15 00:39:51 UTC

Created attachment 73300 [details]
log of removing external btrfs drive and re-attaching it

The kernel no longer crashes when I remove the drive (which is great!), but btrfs doesn't recover gracefully from the error condition. With 3.4-rc7 if I remove the drive I get a warning from btrfs (see log) and when I reattach the drive the system sees it, but btrfs cannot mount it. Attempts to mount via nautilus receive the error "An operation is already pending". Should I log a separate bug for this?