[OpenAFS] 1.3.84 opps on 2.6.11 kernels caught

[Thomas Mueller]

Hi,

we've got similar oopses on Scientific Linux 4.0 (RHEL 4) with
1.3.84 and kernel 2.6.9-11.ELsmp:

 Unable to handle kernel NULL pointer dereference at virtual address 0000001a
  printing eip:
 0219cbd1
 *pde = 00004001
 Oops: 0000 [#1]
 SMP
 Modules linked in: libafs(U) md5 ipv6 ipt_REJECT ipt_LOG ipt_multiport ipt_state ip_conntrack iptable_filte
r ip_tables dm_mod button battery ac 3c59x tg3 floppy ext3 jbd aic7xxx sd_mod scsi_mod
 CPU:    1
 EIP:    0060:[<0219cbd1>]    Tainted: PF     VLI
 EFLAGS: 00010282   (2.6.9-11.ELsmp)
 EIP is at inode_doinit_with_dentry+0x26/0x5a5
 eax: 00000000   ebx: b1df7d24   ecx: b1df7ce4   edx: b1df7ce4
 esi: b1df7ce4   edi: b1df7ce4   ebp: b1df7ce4   esp: bc0a8e58
 ds: 007b   es: 007b   ss: 0068
 Process bash (pid: 29480, threadinfo=bc0a8000 task=e3120190)
 Stack: 00000000 00000000 00000000 d9a38800 022bb5bb b1df7d24 d9a38800 b1df7ce4
        b1df7ce4 0216863c 00000000 bc0a8ea4 00000000 e548be27 b1df7d58 da322c54
        00008180 c8d56400 d9a38800 00008000 0000780c 00000000 0000003e 00001000
 Call Trace:
  [<022bb5bb>] __cond_resched+0x14/0x39
  [<0216863c>] d_instantiate+0x54/0x58
  [<e548be27>] afs_linux_create+0x18d/0x20c [libafs]
  [<02160ae3>] vfs_create+0xb8/0xef
  [<02160eab>] open_namei+0x177/0x5b5
  [<0215396f>] filp_open+0x23/0x3c
  [<02153c81>] sys_open+0x31/0x7d
 Code: <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
 in_atomic():0[expected: 0], irqs_disabled():1
  [<0211e39b>] __might_sleep+0x7d/0x8a
  [<0214f4bb>] rw_vm+0xdb/0x282
  [<0219cba6>] selinux_proc_get_sid+0xca/0xcf
  [<0219cba6>] selinux_proc_get_sid+0xca/0xcf
  [<0214f915>] get_user_size+0x30/0x57
  [<0219cba6>] selinux_proc_get_sid+0xca/0xcf
  [<021061af>] show_registers+0x115/0x16c
  [<02106346>] die+0xdb/0x16b
  [<02120af0>] vprintk+0x136/0x14a
  [<021198a3>] do_page_fault+0x421/0x5e7
  [<0219cbd1>] inode_doinit_with_dentry+0x26/0x5a5
  [<021a622a>] constraint_expr_eval+0x10e/0x21c
  [<021a81ab>] cond_compute_av+0x2b/0x84
  [<0219b256>] avc_insert+0x115/0x11f
  [<02119482>] do_page_fault+0x0/0x5e7
  [<0219cbd1>] inode_doinit_with_dentry+0x26/0x5a5
  [<022bb5bb>] __cond_resched+0x14/0x39
  [<0216863c>] d_instantiate+0x54/0x58
  [<e548be27>] afs_linux_create+0x18d/0x20c [libafs]
  [<02160ae3>] vfs_create+0xb8/0xef
  [<02160eab>] open_namei+0x177/0x5b5
  [<0215396f>] filp_open+0x23/0x3c
  [<02153c81>] sys_open+0x31/0x7d
  Bad EIP value.
  <0>Fatal exception: panic in 5 seconds
 
How could we help to track this down?
Or is there already a fix around which i missed?

Thomas.

On Fri, 24 Jun 2005, Jason McCormick wrote:

>   I've finally managed to capture the oops for the crash that has been
> plaguing is on FC3 w/ 2.6.11 kernels using 1.3.84.  The crash is below:
> 
> GS: 00010286   (2.6.11-1.27_FC3smp)
> EIP is at inode_doinit_with_dentry+0x21/0x63b
> eax: f6bf3800   ebx: d63dfe30   ecx: f6bf3800   edx: d63dfe30
> esi: f6bf3800   edi: 00000000   ebp: d63dfe30   esp: c52b3e30
> ds: 007b   es: 007b   ss: 0068
> Process bash (pid: 22216, threadinfo=c52b3000 task=d2299560)
> Stack: 00000146 f755c524 c01bd35c 00000002 2000c073 000000c2 00000000
> 00000000
>        00000000 c01b11f5 00000001 f6bf3800 d63dfe6c d63dfe30 d63dfe30
> c017278a
>        c52b3ea0 00008180 00000000 f8cdfc1f 00000001 00008180 c52b3e9c
> f75db150
> Call Trace:
>  [<c01bd35c>] security_compute_sid+0x193/0x2fc
>  [<c01b11f5>] avc_has_perm+0x4e/0x58
>  [<c017278a>] d_instantiate+0x54/0x58
>  [<f8cdfc1f>] afs_linux_create+0x17d/0x1e6 [libafs]
>  [<c0168847>] permission+0x8f/0xa6
>  [<c016a132>] vfs_create+0xa1/0xfb
>  [<c016a4a3>] open_namei+0xe6/0x635
>  [<c015bd23>] filp_open+0x27/0x46
>  [<c015bfb3>] get_unused_fd+0x9a/0xc2
>  [<c015c085>] sys_open+0x31/0x7e
>  [<c0103f0f>] syscall_call+0x7/0xb
> Code: 89 d8 83 c4 10 5b 5e 5f 5d c3 55 57 56 89 c6 53 89 d3 83 ec 2c 8b b8
> 54 01 00 00 c7 44 24 1c 00 00 00 00 c7 44 24 18 00 00 00
> 00 <80> 7f 1a 00 0f 85 cf 00 00 00 ba 6b 00 00 00 b8 1f d3 30 c0 e8
> 
> I haven't bee able to pay real close attention to the OpenAFS lists in the
> last few weeks, but I don't think a fix for this has been sent around...
> 
>