Created attachment 37032 [details] Part of the syslog with the Oops trace System Debian GNU/Linux x86_64 Processor Athlon 64 II, 4GB DDR3 Hi, I've an USB key with a FAT filesystem. What happenend: - mounted the key - modified a file on the key - unmounted the key - got the Oops Attached the related part of the syslog and .config Regards Jean-Luc
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
Um.. I can't still reproduce this. You can this reproduce always, or it happens sometimes? BTW, I tried: 1) startx 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] 3.0.0-rc1 kern.log 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 > which > is used from tracker daemon. And probably VFS passed NULL to FAT as inode > pointer. 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.
https://lkml.org/lkml/2011/6/10/155 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. ***