[gamin] kernel oops when removing a wathced directory

[Egmont Koblinger <egmont uhulinux hu>]

Hi,

The subject says it all :-))  The rest are just boring details...

I'm using an overpatched 2.6.9-rc3 with inotify patch 0.12.0. Previously I
had an overpatched 2.6.9-rc2 with inotify 0.9.2, and that one worked fine.
I'm just compiling a vanilla+inotify kernel to try that one...

Here's what I do to reproduce the bug:
Copy-paste monitor.c (Example 8-1) from
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Developer/books/IIDsktp_IG/sgi_html/ch08.html
replace GETfd with GETFD and compile it

$ mkdir /tmp/foobar
$ ./monitor /tmp/foobar
;     keep trying patiently until it starts successfully, often it exits with
;     a "Success" error :)
;     Then in another terminal:
$ rmdir /tmp/foobar
Segmentation fault
$ dmesg
Unable to handle kernel paging request at virtual address 0001041b
 printing eip:
c0425623
*pde = 00000000
Oops: 0002 [#1]
SMP
Modules linked in: [long list...]
CPU:    1
EIP:    0060:[<c0425623>]    Tainted: P   VLI
EFLAGS: 00210216   (2.6.9-rc3-1)
EIP is at _spin_lock+0x3/0x20
eax: 0001041b   ebx: dd7ca988   ecx: c04b2550   edx: dd7ca988
esi: ce1210c4   edi: ce1210c4   ebp: d7bbdf00   esp: d7bbdf00
ds: 007b   es: 007b   ss: 0068
Process rmdir (pid: 10491, threadinfo=d7bbc000 task=c3613000)
Stack: d7bbdf18 c036f65d 00000000 dd7ca988 ce1210c4 ce1210c4 d7bbdf30 c036f849
       dd7ca988 00000000 00000000 c792f320 d7bbdf60 c016a9c4 ce1210c4 ce1210c4
       00000800 00000000 de70ea24 00000080 c792f38c c792f320 d06b0000 c792f320
Call Trace:
 [<c0108405>] show_stack+0x75/0x90
 [<c0108565>] show_registers+0x125/0x190
 [<c010873a>] die+0xda/0x160
 [<c011d2f0>] do_page_fault+0x2b0/0x5de
 [<c0107fdd>] error_code+0x2d/0x40
 [<c036f65d>] ignore_helper+0x1d/0xb0
 [<c036f849>] inotify_inode_is_dead+0x29/0x50
 [<c016a9c4>] vfs_rmdir+0x134/0x220
 [<c016ab39>] sys_rmdir+0x89/0xe0
 [<c0106ea7>] syscall_call+0x7/0xb
Code: 00 00 00 01 0f 94 c0 84 c0 b9 01 00 00 00 75 09 f0 81 02 00 00 00 01
31 c9 89 c8 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 <f0> fe 08 79 09
f3 90 80 38 00 7e f9 eb f2 5d c3 8d b6 00 00 00

Further attempts to access the contents of /tmp/foobar cause no more oops or
segfault, rather the process (rmdir or whatever) stucks in 'D' state
forever...


bye,
Egmont