Bug 50841
| Summary: | cant read from cifs share mounted with 'cache=none' (SMB response too short) | ||
|---|---|---|---|
| Product: | File System | Reporter: | Fadeeva Marina (astarta) |
| Component: | CIFS | Assignee: | Jeff Layton (jlayton) |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | alan, fs_cifs, jlayton, sprabhu |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.5.x/3.6.x | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | successful read of the same file using 3.4 kernel (share mounted with directio) | ||
|
Description
Fadeeva Marina
2012-11-21 09:49:30 UTC
Created attachment 86841 [details]
successful read of the same file using 3.4 kernel (share mounted with directio)
Thanks for the bug report, I'll look at it as soon as I'm able. I don't see the "messages.bad" file attached here, but I'll probably need to reproduce this to track it down anyway. The attachment appeared to be too big :) uploaded it to external server. see at: www.rat.ru/astarta/messages.bad Thank you for your attention! I was able to reproduce this and from looking at a capture, this appears to be a bug in samba. It's sending malformed frames in response to the read requests we're making. The SMB responses are 4 bytes of zeroes and that's it. I'll report this to the samba folks, and mention that it's a regression from earlier versions of samba. Depending on your I/O sizes, you may be able to work around this problem temporarily by mounting with a lower rsize= value. Maybe try something like rsize=61440 or so? No idea if that'll help, but it may be worth experimenting with. Ok, I see. Thank you for your kind explanation! I question thought, if samba server is somehow broken and responds with malformed frames, shouldn't the kernel work around this issue and avoid looping with 'SMB response too short' message? Earlier kernels (3.4 and older) worked in this case, even with such malformed frames. Also it's not clear why revering the 'cifs: convert cifs_iovec_read to use async reads' patch helps? Probably the patch is somehow wrong? > Ok, I see. Thank you for your kind explanation! > > I question thought, if samba server is somehow broken and responds with > malformed frames, shouldn't the kernel work around this issue and avoid > looping > with 'SMB response too short' message? > Earlier kernels (3.4 and older) worked in this case, even with such malformed > frames. That would be nice, but it's difficult to handle in practice. All we see is that the server sent us this bogus reply. Because it's not even long enough to get to the MID we can't identify it as the response to any particular request, so we have no way to issue a clear error back to the caller. > Also it's not clear why revering the 'cifs: convert cifs_iovec_read to use > async reads' patch helps? Probably the patch is somehow wrong? No, I'm fairly certain the patch is fine. What it does is make the code use asynchronous and larger read requests on the wire. It's likely that the larger reads are what triggers the bug on the server, which is why I suggested artificially limiting the rsize in the code as a potential workaround. Bug reported to samba.org bugzilla here:
https://bugzilla.samba.org/show_bug.cgi?id=9422
I'll plan to close this as NOTABUG once we have some acknowledgement from the samba folks on the problem.
> Earlier kernels (3.4 and older) worked in this case, even with such malformed
> frames.
Oh, and I doubt earlier kernels ever saw these malformed frames -- this is almost certainly triggered by the fact that we issue larger read requests (which the server is claiming to support). They certainly were not any better equipped to deal with them and would almost certainly loop indefinitely like this if they saw them.
Volker from the samba team has generated a patch that seems to fix this in samba. At this point, I'm going to close this as INVALID since it wasn't a kernel bug, but rather one in samba. Thank you for your help! It's greatly appreciated! |