Bug 10451
| Summary: | Oops when trying to mount remote CIFS share | ||
|---|---|---|---|
| Product: | File System | Reporter: | Olivier Berger (oberger) |
| Component: | CIFS | Assignee: | Steve French (sfrench) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | high | CC: | bunk, gege, olivier.berger, shirishp |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.25.3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
debug data from comment #6
Fix for mount oops |
||
|
Description
Olivier Berger
2008-04-13 23:09:15 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). Actually tested on Debian kernel 2.6.25-2-686 (2.6.25-3) which contains kernel 2.6.25.3. When the oops happens, what are the contents in the file /proc/fs/cifs/DebugData? 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 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 Hello, I have the same problem here! Kernel: 2.6.28.2, 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 Created attachment 20164 [details] debug data from comment #6 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. by changing a test version of Samba server slightly (to return a null OS field) I was able to reproduce the problem. 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[0] to null
Fix attached. Will try to push this upstream ASAP if it tests out ok for you
Pushed into cifs-2.6.git and cc:stable Tested with 2.6.28.5, your patch solved the problem! Thank you!! Tested with 2.6.26 and it solves the problem successfully. Many thanks indeed |