[linux-cifs-client] kernel BUG at /tmp/cifs-2.6-devel/fs/cifs/cifs_dfs_ref.c:274!

[Jeff Layton]

On Fri, 19 Sep 2008 09:56:00 -0400 (EDT)
"Peter J. Desnoyers" <pjd at ccs.neu.edu> wrote:

> Mounting an SMB share from what I believe is a netapp filer. Tcpdump capture of the transaction can be found at http://www.ccs.neu.edu/~pjd/cifs-bug.pkt.
> 
> The capture shows (1) mounting the share, and (2) doing an 'ls' of the mounted directory. At which point it fails with the following bug. I've tried the new 1.54 code, and it seems to fail in the same way; a quick scan of the mailing list archives doesn't show any discussion of this particular part of the code.
> 
> ------------[ cut here ]------------
> kernel BUG at /tmp/cifs-2.6-devel/fs/cifs/cifs_dfs_ref.c:274!
> invalid opcode: 0000 [#1] SMP 
> Modules linked in: nls_utf8 cifs bridge llc bnep rfcomm l2cap bluetooth fuse sunrpc ipv6 loop dm_multipath sr_mod cdrom floppy ata_generic pcspkr pcnet32 mii ata_piix pata_acpi sg libata i2c_piix4 i2c_core ac dm_snapshot dm_zero dm_mirror dm_log dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd mbcache [last unloaded: microcode]
> 
> Pid: 4050, comm: ls Not tainted (2.6.26.3 #1)
> EIP: 0060:[<e0a53929>] EFLAGS: 00010246 CPU: 0
> EIP is at cifs_dfs_follow_mountpoint+0x3b/0x627 [cifs]
> EAX: c81125b0 EBX: c81125b0 ECX: e0a6c524 EDX: df60def4
> ESI: da01d2a4 EDI: df46b180 EBP: df60de34 ESP: df60dde8
>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> Process ls (pid: 4050, ti=df60d000 task=de862f80 task.ti=df60d000)
> Stack: df60de04 df60def4 00000001 00000246 c1754180 df888a00 c1754180 df60de10 
>        df888168 df888100 df46b180 df60de34 c049fd51 da01d2a4 00000000 00000000 
>        00000000 da01d2a4 df46b180 df60de90 c0494125 df60def4 df46b187 00000003 
> Call Trace:
>  [<c049fd51>] ? mntput_no_expire+0x1a/0xfe
>  [<c0494125>] ? __link_path_walk+0x9f9/0xd3a
>  [<c040948f>] ? native_sched_clock+0xac/0xc8
>  [<c0444671>] ? lock_release_holdtime+0x1a/0x115
>  [<c04944b2>] ? path_walk+0x4c/0x9b
>  [<c04947a0>] ? do_path_lookup+0x198/0x1e1
>  [<c04936d9>] ? getname+0x64/0xb7
>  [<c04950d6>] ? __user_walk_fd+0x2f/0x43
>  [<c048ec54>] ? vfs_stat_fd+0x19/0x40
>  [<c040948f>] ? native_sched_clock+0xac/0xc8
>  [<c048ed2a>] ? vfs_stat+0x11/0x13
>  [<c048ed40>] ? sys_stat64+0x14/0x28
>  [<c046028a>] ? audit_syscall_entry+0xf9/0x123
>  [<c040a94b>] ? do_syscall_trace+0x138/0x17f
>  [<c0404ad6>] ? syscall_call+0x7/0xb
>  =======================
> Code: e0 01 89 55 b8 c7 45 f0 00 00 00 00 c7 45 ec 00 00 00 00 74 11 68 bc 70 a5 e0 68 40 60 a6 e0 e8 71 93 bd df 59 5e 3b 5b 34 75 04 <0f> 0b eb fe e8 3a 78 ff ff f6 05 80 d7 a6 e0 01 89 45 bc 74 21 
> EIP: [<e0a53929>] cifs_dfs_follow_mountpoint+0x3b/0x627 [cifs] SS:ESP 0068:df60dde8
> ---[ end trace 9b63568ea567a49d ]---
> 


What's the actual mount command you're using here? Particularly the
"device" argument of the mount.

PS: looks like the capture shows the machine claiming to be a Win2k3
box...

-- 
Jeff Layton <jlayton at redhat.com>