Bug#416524: linux-image-2.6.18-5-xen-amd64: Kernel BUG at fs/fuse/control.c:82
Ok... got it reproduced on 2.6.18.dfsg.1-13etch4:
What I just did:
- bootstrap a new lenny domU, run it with kernel 2.6.18-xen-amd64
(2.6.18.dfsg.1-13etch4)
- install libfuse2 and fuse-utils 2.7.0-2 (from snapshot.debian.net)
- create a user account, add it to the fuse group, load fuse module etc
- log in as the new regular user
- create a sshfs mount to another host
- actually *use* the mount - important!! - just open a random textfile
with less or whatever, but cd into it and do something there...
- as root: apt-get upgrade the fuse stuff to 2.7.0-3
fuse:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
fuse-utils libfuse2
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/140kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
(Reading database ... 10096 files and directories currently installed.)
Preparing to replace fuse-utils 2.7.0-2 (using
.../fuse-utils_2.7.0-3_amd64.deb) ...
Unpacking replacement fuse-utils ...
Preparing to replace libfuse2 2.7.0-2 (using
.../libfuse2_2.7.0-3_amd64.deb) ...
Unpacking replacement libfuse2 ...
Setting up libfuse2 (2.7.0-3) ...
Setting up fuse-utils (2.7.0-3) ...
creating fuse device node...
udev active, devices will be created in /dev/.static/dev/
creating fuse group...
/etc/init.d/fuse: line 30: 3985 Segmentation fault mount -t
fusectl fusectl $MOUNTPOINT >/dev/null 2>&1
Message from syslogd@fuse at Tue Oct 30 21:20:37 2007 ...
fuse kernel: invalid opcode: 0000 [1] SMP
fuse:~#
/var/log/syslog shows the same error with call trace:
Oct 30 21:20:37 fuse kernel: ----------- [cut here ] --------- [please
bite here ] ---------
Oct 30 21:20:37 fuse kernel: Kernel BUG at fs/fuse/control.c:82
Oct 30 21:20:37 fuse kernel: invalid opcode: 0000 [1] SMP
Oct 30 21:20:37 fuse kernel: CPU 1
[..snip..]
fusermount -u hangs when the user tries to umount the sshfs mount.
A system halt executed by root hangs...
fuse:~# halt
Broadcast message from root@fuse (pts/0) (Tue Oct 30 21:23:21 2007):
The system is going down for system halt NOW!
logging in with xm console shows a /bin/umount -i /path/to/sshfsmount
that's blocking:
4393 pts/1 D 0:00 /bin/umount -i /path/to/sshfsmount
4998 pts/0 D+ 0:00 shutdown -h 0 w
I cannot kill dash nine or do anything to stop this process 4393... So I
have to do a xm destroy from the dom0.
When the sshfs mount I made was not in use upgrading libfuse/fuse-utils
went just fine, and afterwards the sshfs mount was gone, so I guess it
was umounted during the fuse upgrade. I guess there's a pointer to what
is going wrong actually?
Now... let's try 2.6.18.dfsg.1-16:
What I did:
- install the linux-image/modules 2.6.18.dfsg.1-16_amd64.deb in dom0
- install the linux-modules 2.6.18.dfsg.1-16_amd64.deb in the domU
- install fuse-foobar 2.7.0-2 again in the domU
- start the domU with kernel 2.6.18.dfsg.1-16
- log in as the existing regular user
- create a sshfs mount to another host
- actually *use* the mount; just open a random textfile with less or
whatever, but cd into it and do something there...
- as root: apt-get upgrade the fuse stuff to 2.7.0-3
fuse:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
fuse-utils libfuse2
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/140kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
(Reading database ... 10097 files and directories currently installed.)
Preparing to replace fuse-utils 2.7.0-2 (using
.../fuse-utils_2.7.0-3_amd64.deb) ...
Unpacking replacement fuse-utils ...
Preparing to replace libfuse2 2.7.0-2 (using
.../libfuse2_2.7.0-3_amd64.deb) ...
Unpacking replacement libfuse2 ...
Setting up libfuse2 (2.7.0-3) ...
Setting up fuse-utils (2.7.0-3) ...
creating fuse device node...
udev active, devices will be created in /dev/.static/dev/
creating fuse group...
fuse:~#
Looks good... Let's see what happened to the mount?
fuse:~# mount | grep sshfs
sshfs#knorrie@anotherhost:/home/knorrie on /home/knorrie/bla type fuse
(rw,nosuid,nodev,max_read=65536,user=knorrie)
It still exists... The other session where this user was accessing a
file on the remote mounted system still responds... It seems the
existing mount was not touched.
So... It seems 2.6.18.dfsg.1-16 fixes this issue, like you suggested.
Perhaps you can shed some light on what exactly was the issue? :)
Perhaps just installing and re-installing 2.7.0-3 over again would
trigger the same situation, but I did choose to reproduce it in a way it
was most like how things went yesterday.
Have fun,
Hans van Kranenburg
Reply to: