[linux-cifs-client] Re:
Steve French
smfrench at austin.rr.com
Mon Dec 13 22:11:29 GMT 2004
The good news is that this function is only called when:
- configured for experimental
- mounting with forcedirectio
let me know if it repros - and I will see if I can pin down the
instruction. Probably need more defensive code in this path in any case
in case the session really crashes out from under us this way. But
the bad news is that I am killing the session when I probably don't need
to be - what seems to be happening is that the tcp peek for the smb
header is strangely only returning 13 bytes (a very strange size, it is
supposed to return almost triple that) but I need 14 bytes to run
checkSMBhdr (since that is where the flag byte is which determines if it
is a request or a response). So the real fix is to either:
1) try harder on the peek if I can't get at least 14 bytes out of it
or
2) skip this first checkSMBhdr (it gets run again after the data is
finally pulled off the socket - but this time with more complete check
as part of checkSMB). There is no harm in running this check if I get a
few more bytes out of the peek.
If this problem is reproducible - can you try this patch. It skips the
checkSMBhdr if the peek returned smaller amount of data than expected.
Gorazd Golob wrote:
>Hi!
>
>I just had another crash on newest cifs code (from bk 3 hours ago)..
>java process was reading from cifs mount point - xp on other side. Here is
>a dmesg (I'm sorry I didn't have set debug in cifsFYI .. I'll try to make
>also one.. didn't need much time to crash it).
>Under dmesg snip in kernel oops with ksymoops
>
>--- dmesg ----
> CIFS VFS: mounting share using direct i/o
> CIFS VFS: Rcvd Request not response
> CIFS VFS: bad smb detected. The Mid=0
> CIFS VFS: Invalid size or format for SMB found with length 13 and
>pdu_length 4164
>Received Data is: : dump of 40 bytes of data at 0xeb370d80
>
> 40100000 424d53ff 0000002e 00000000 . . . @ ÿ S M B . . . . . . . .
> 00000000 00000000 00000000 00000000 . . . . . . . . . . . . . . . .
> 00000000 00000000 . . . . . . . .
> CIFS VFS: No response buffer
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
> CIFS VFS: No response buffer
> CIFS VFS: Send error in read = -11
>Unable to handle kernel NULL pointer dereference at virtual address
>00000031
> printing eip:
>c01bb794
>*pde = 00000000
>Oops: 0000 [#1]
>SMP
>Modules linked in:
>CPU: 0
>EIP: 0060:[<c01bb794>] Not tainted VLI
>EFLAGS: 00010282 (2.6.10-rc3)
> CIFS VFS: Send error in read = -9
>eax: 00000000 ebx: 00001004 ecx: 00000053 edx: c0351420
>esi: f5c9ae00 edi: 0034f358 ebp: 0000a028 esp: f56bff48
>ds: 007b es: 007b ss: 0068
>Process java (pid: 5368, threadinfo=f56be000 task=ee6ffa60)
>Stack: 00000000 f7f32a60 081a37b0 f71b0be0 fffffff5 00000000 00000000
>00000000
> f4ba1920 f56bffac 00019000 c0140990 f4ba1920 08199788 00019000
>f56bffac
> f4ba1920 fffffff7 00019000 f56be000 c0140b89 f4ba1920 08199788
>00019000
>Call Trace:
> [<c0140990>]
> [<c0140b89>]
> [<c0102ad7>]
>Code: 14 50 8b 4c 24 40 ff 71 04 ff 31 53 8b 54 24 14 0f b7 42 18 50 56 57
>e8 88 2a ff ff 89 44 24 2c 8b 44 24 34 83 c4 20 ff 74 24 10 <0f> b7 50 31
>8d 44 02 04 50 ff 74 24 0c e8 34
><3> CIFS VFS: Send error in read = -9
>60 01 00 83 c4 0c
> <3> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in read = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
> CIFS VFS: Send error in Close = -9
>
>--- dmesg with ksymoops --
>
>
>
>>>EIP; c01bb794 <cifs_user_read+14e/241> <=====
>>>
>>>
>
>
>
>>>edx; c0351420 <table+0/20>
>>>esi; f5c9ae00 <pg0+35894e00/3fbf8400>
>>>esp; f56bff48 <pg0+352b9f48/3fbf8400>
>>>
>>>
>
>Trace; c0140990 <vfs_read+96/c0>
>Trace; c0140b89 <sys_read+3b/63>
>Trace; c0102ad7 <syscall_call+7/b>
>
>This architecture has variable length instructions, decoding before eip
>is unreliable, take these instructions with a pinch of salt.
>
>Code; c01bb75a <cifs_user_read+114/241>
>00000000 <_EIP>:
>Code; c01bb75a <cifs_user_read+114/241>
> 0: 14 50 adc $0x50,%al
>Code; c01bb75c <cifs_user_read+116/241>
> 2: 8b 4c 24 40 mov 0x40(%esp),%ecx
>Code; c01bb760 <cifs_user_read+11a/241>
> 6: ff 71 04 pushl 0x4(%ecx)
>Code; c01bb763 <cifs_user_read+11d/241>
> 9: ff 31 pushl (%ecx)
>Code; c01bb765 <cifs_user_read+11f/241>
> b: 53 push %ebx
>Code; c01bb766 <cifs_user_read+120/241>
> c: 8b 54 24 14 mov 0x14(%esp),%edx
>Code; c01bb76a <cifs_user_read+124/241>
> 10: 0f b7 42 18 movzwl 0x18(%edx),%eax
>Code; c01bb76e <cifs_user_read+128/241>
> 14: 50 push %eax
>Code; c01bb76f <cifs_user_read+129/241>
> 15: 56 push %esi
>Code; c01bb770 <cifs_user_read+12a/241>
> 16: 57 push %edi
>Code; c01bb771 <cifs_user_read+12b/241>
> 17: e8 88 2a ff ff call ffff2aa4 <_EIP+0xffff2aa4>
>Code; c01bb776 <cifs_user_read+130/241>
> 1c: 89 44 24 2c mov %eax,0x2c(%esp)
>Code; c01bb77a <cifs_user_read+134/241>
> 20: 8b 44 24 34 mov 0x34(%esp),%eax
>Code; c01bb77e <cifs_user_read+138/241>
> 24: 83 c4 20 add $0x20,%esp
>Code; c01bb781 <cifs_user_read+13b/241>
> 27: ff 74 24 10 pushl 0x10(%esp)
>Code; c01bb785 <cifs_user_read+13f/241>
> 2b: 0f b7 50 31 movzwl 0x31(%eax),%edx
>Code; c01bb789 <cifs_user_read+143/241>
> 2f: 8d 44 02 04 lea 0x4(%edx,%eax,1),%eax
>Code; c01bb78d <cifs_user_read+147/241>
> 33: 50 push %eax
>Code; c01bb78e <cifs_user_read+148/241>
> 34: ff 74 24 0c pushl 0xc(%esp)
>Code; c01bb792 <cifs_user_read+14c/241>
> 38: e8 .byte 0xe8
>Code; c01bb793 <cifs_user_read+14d/241>
> 39: 34 .byte 0x34
>
>This decode from eip onwards should be reliable
>
>Code; c01bb794 <cifs_user_read+14e/241>
>00000000 <_EIP>:
>Code; c01bb794 <cifs_user_read+14e/241> <=====
> 0: 00 00 add %al,(%eax) <=====
>Code; c01bb796 <cifs_user_read+150/241>
> 2: 00 00 add %al,(%eax)
>
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cifs_oops_fix.diff
Type: text/x-patch
Size: 707 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20041213/22527747/cifs_oops_fix-0001.bin
More information about the linux-cifs-client
mailing list