> 2) After running a recent 2.1.115 kernel, I'm getting the Oops repeatable,
> while starting autofs.:
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> current->tss.cr3 = 00776000, `r3 = 00776000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c188e9da>]
> EFLAGS: 00010292
> eax: 0000001c ebx: c0090000 ecx: c0bc4000 edx: c01bfc8c
> esi: c01f1bac edi: 00000000 ebp: c077a000 esp: c077becc
> ds: 0018 es: 0018 ss: 0018
> Process mount (pid: 396, process nr: 20, stackpage=c077b000)
> Stack: c1890354 00000002 c01f1bd4 c0741000 c077bef0 c06f57a0 c088c208 00000003
> 00000002 00000005 c012b7cd c01f1bac c070e000 00000000 c06f5700 ffffffea
> 00000002 00000002 c012bc18 00000002 c188ff3a 00000000 c070e000 00000000
> Call Trace: [<c1890354>] [<c012b7cd>] [<c012bc18>] [<c188ff3a>]
> [<c188ff3a>] [<c012c11e>] [<c188ff3a>] [<c0109d08>]
> Code: 8b 7f 04 89 7c 24 18 57 68 40 00 89 c1 e8 98 6e 88 fe 8b 44
>
> The problem is in the file fs/autofs/inode.c:206, the inlined function fget()
> calles fcheck(), and this function dereference current->files, which is this
> case NULL. There are no changes to the autofs-code from 2.1.111 to 2.1.115.
> I have no idea to search for. Since a build the autofs as modul I can't
> remove it. Also the umounting of all filesystems at shutdown hangs.
The fget() function should never be called from a context where current->files is
NULL. Calling fget() implies that the caller wants to do something with files,
and you need a files struct for this. So this isn't an autofs bug, but rather a
problem with the way it's being invoked.
Can you do some further investigation to find how autofs is getting called in
this way? (I.e. what volume it's trying to mount, and what process asked for that
volume, etc.)
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html