|Summary:||Oops when trying to mount remote CIFS share|
|Product:||File System||Reporter:||Olivier Berger (oberger)|
|Component:||CIFS||Assignee:||Steve French (sfrench)|
|Severity:||high||CC:||bunk, gege, olivier.berger, shirishp|
debug data from comment #6
Fix for mount oops
Description Olivier Berger 2008-04-13 23:09:15 UTC
Comment 1 Olivier Berger 2008-05-23 14:18:09 UTC
FYI, I tested with Debian kernel 2.6.25-2-686, and still crashing (more details at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463402).
Comment 2 Olivier Berger 2008-05-23 14:46:54 UTC
Actually tested on Debian kernel 2.6.25-2-686 (2.6.25-3) which contains kernel 18.104.22.168.
Comment 3 Shirish Pargaonkar 2009-01-31 16:49:57 UTC
When the oops happens, what are the contents in the file /proc/fs/cifs/DebugData?
Comment 4 Steve French 2009-02-03 08:12:04 UTC
Looking at this today in trying to cleanout old bugs that had fallen through the cracks - we need more information since it does not appear that these fields can be null in the cifs_strfromUCSle function and it is not obvious to me or other developers at first glance why/what is wrong in decode_unicode_ssetup in fs/cifs/sess.c. Would you turn on debugging and attach (or forward via email) the trace. you can do: 1) "dmesg -c" (to clear the message log) 2) "echo 7 > /proc/fs/cifs/cifsFYI" (to enable cifs debugging) 3) mount 4) "echo 0 > /proc/fs/cifs/cifsFYI" (to turn off cifs debugging messages) 5) dmesg > error-log-from-mount and email or attach the error-log-from-mount If you are comfortable building your own kernel, then it would also be helpful to enable memory debugging in the "kernel hacking" part of the kernel configuration: e.g. some set of debug slab memory allocations, debug vm, compile kernel with frame pointers, debug page memory, check for stack overflows, write protect read only structures
Comment 5 Steve French 2009-02-03 08:15:44 UTC
To verify whether the NAS appliance has sent a corrupt SMB SessionSetup response, it would also be helpful if we could get a network trace of the failed mount. See http://wiki.samba.org/index.php/Capture_Packets for information on how to take a network trace if you are not familiar with it
Comment 6 Michael Geiger 2009-02-08 03:37:04 UTC
Hello, I have the same problem here! Kernel: 22.214.171.124, running on an AMD 64 X2 (SuSE 11.1 64bit, vanilla kernel) I tried to mount a NAS device (Raidsonic ICY BOX IB-NAS900) with this fstab entry: //elenas/musik /mnt/ele cifs noauto,credentials=/etc/fstab.cred.ele,uid=share,gid=users,file_mode=0640,dir_mode=0750,noacl,iocharset=iso8859-1 0 0 To help you with this bug I'll attach bug-10451-gege.tgz including these files: boot.txt dmesg from system boot config.gz Kernel config debugdata.txt content from /proc/fs/cifs/DebugData mount-oops.txt output from dmesg (as suggested in comment #4) net.dump tcpdump from mount attempt Michael
Comment 7 Michael Geiger 2009-02-08 03:38:19 UTC
Created attachment 20164 [details] debug data from comment #6
Comment 8 Steve French 2009-02-16 10:16:43 UTC
The OS and the Network OS fields in the SMB response are empty (one character of null), which is quite unusual. This may be the reason that session setup has problems parsing this response.
Comment 9 Steve French 2009-02-16 13:04:36 UTC
by changing a test version of Samba server slightly (to return a null OS field) I was able to reproduce the problem.
Comment 10 Steve French 2009-02-16 14:33:08 UTC
Created attachment 20269 [details] Fix for mount oops When the length of the OS or NOS field was null we were not allocating any memory for them and thus would oops when we set the serverNOS to null Fix attached. Will try to push this upstream ASAP if it tests out ok for you
Comment 11 Steve French 2009-02-16 18:18:24 UTC
Pushed into cifs-2.6.git and cc:stable
Comment 12 Michael Geiger 2009-02-17 07:25:04 UTC
Tested with 126.96.36.199, your patch solved the problem! Thank you!!
Comment 13 Olivier Berger 2009-03-01 23:06:38 UTC
Tested with 2.6.26 and it solves the problem successfully. Many thanks indeed