Created attachment 519571 [details] kernel oops Description of problem: Trying to mount a cifs share on Kernel 2.6.40 fails with a kernel oops, probably if the share name contains a $ sign.
Created attachment 519572 [details] cifs Debug with cifsFYI set to 7
Does the patch here fix this? http://marc.info/?l=linux-cifs&m=131394062707968&w=2
Is there already a build available for Fedora, containing the above patch?
No, not yet -- I'll see if I can get one together here later today.
I think I've got a scratch build going with that patch + one other. Can you test it once it completes? https://koji.fedoraproject.org/koji/taskinfo?taskID=3298071
Dear Jeff. Yes, that patch did the trick. Do you think you could also include it in the next update?
Just a side note. This is logged in dmesg on the client: CIFS VFS: strtoUCS: char2uni of 0xfffffff9 returned -22 But it does not seem to have any noticeable effect.
Thanks for testing it. I'll see about getting that patch + one other into fedora kernels soon. I think the strtoUCS message is unrelated -- it just means that cifs tried to decode a character (probably in a filename) that couldn't be decoded into your codepage.
Strangely the problem only seems to occur sometimes on the unpatched 2.6.40. Do you have any Idea why? I have never experienced it again in the patched kernel till now, btw.
Yes... in some cases, lookup_one_len may return a valid dentry pointer. If that happens, then everything will work. It's only when it returns an ERR_PTR that this will blow up.
The patch is now in f15 and will be in the next kernel release.
kernel-2.6.40.4-5.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/kernel-2.6.40.4-5.fc15
kernel-2.6.40.4-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
No word in some time, so I'm assuming this is now fixed. Please reopen if you're still having problems.