Created attachment 37032 [details]
Part of the syslog with the Oops trace
System Debian GNU/Linux x86_64
Processor Athlon 64 II, 4GB DDR3
I've an USB key with a FAT filesystem.
- mounted the key
- modified a file on the key
- unmounted the key
- got the Oops
Attached the related part of the syslog and .config
Created attachment 37042 [details]
.config file of the running kernel
sorry for late reply.
I tried to reproduce this, but couldn't reproduce on 2.6.38-rc6.
Please re-tested on recent kernel?
BTW, this seems to be not FAT specific problem. Because oops is on inotify which
is used from tracker daemon. And probably VFS passed NULL to FAT as inode pointer.
It seems still can happen on recent kernels, on final 2.6.38 I saw recently a similar oops: http://launchpadlibrarian.net/66845909/OopsText.txt from http://bugs.launchpad.net/bugs/738876
I can't still reproduce this. You can this reproduce always, or it happens
BTW, I tried:
2) tracker-control -s
3) mount /dev/sdc1 ~/mnt
4) cp -a foo ~/mnt
5) umount ~/mnt
If you have more detail to reproduce, please let me know.
I can't reproduce myself too, I just mean that I received a bug report about same issue with oops on 2.6.38. I tried here to produce a working testcase but still no success.
Created attachment 61342 [details]
I managed to reproduce this with the latest kernel sources. The log attached.
I can reproduce this quite easily by executing mount/umount script and testprogram executing continuously inotify_add_watch/inotify_rm_watch loop.
I will attach the script and testprogram also.
I have been able to reproduce this only in single core PC, I was not able to reproduce it in my multicore CPU.
The root cause seems to be that iput is executed after the filesystem has been already removed. iput can be executed even after unmounting, because generic_shutdown_super exits with some busy inodes left, which can be seen from the log message "VFS: Busy inodes after unmount of sda2. Self-destruct in 5 seconds. Have a nice day..."
Created attachment 61352 [details]
inotify loop test program
Created attachment 61362 [details]
mount / umount script
(In reply to comment #3)
> BTW, this seems to be not FAT specific problem. Because oops is on inotify
> is used from tracker daemon. And probably VFS passed NULL to FAT as inode
You are right. I have reproduced the oops also with ext4 FS, so this should be moved to inotify instead of FAT/VFAT/MSDOS.
Could somebody update also the kernel version of this bug, since I am able to reproduce this with latest kernel. It seems I do not have rights to do that.
Update for current state. Please see the above thread.
No fix has been committed; please reopen.
inotify's fixes was merged at 3.8 devlopment.
*** Bug 53431 has been marked as a duplicate of this bug. ***