On 03/27/2013 10:15 PM, Steve French wrote: > On Wed, Mar 27, 2013 at 8:11 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> >> On Wed, 27 Mar 2013 17:39:30 -0400 >> Michael Mol <mikemol@xxxxxxxxx> wrote: >> >>> I notice the patch in this message >>> >>> http://thread.gmane.org/gmane.linux.kernel.cifs/7655/focus=7671 >>> >>> Never made it into Linus's tree. It's also not in Debian or RedHat's >>> kernels. I'm running into this on CentOS. >>> >>> Has there been any activity on this issue since December? >>> >>> Incidentally, I filed a bug report on bugs.redhat.com relating to what >>> I'm hitting: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=928516 >>> >> >> If you have a support contract with Red Hat, then it would be best to >> open a support case, which will help make the case for its inclusion >> into the RHEL kernel. >> >>> I'm looking for a good reason to (or to not) apply the patches to the >>> current RH kernel on my systems; I rather need it for my current project. >>> >>> (I'd respond via the linux-cifs list, but Thunderbird is being a PITA >>> and preventing me from subscribing to it via gmane's NNTP, through which >>> I'd be able to reply to the thread directly...) >>> >> >> You're correct that it never made it in. I think the patch makes >> sense...Steve, was there some reason you didn't merge it? >> >> In the meantime, if you're able to test the patch and reply on-list >> with the results then that would be helpful. >> >> Thanks, >> -- >> Jeff Layton <jlayton@xxxxxxxxxx> > > > > I don't remember getting any other test feedback on it - do we have > some additional tested-by to add (or anyone else review it). I didn't > personally try it (I was traveling during the holiday break when it > was discussed) and I didn't see it in Jeff's tree so I assumed that he > found a problem with it. > > Does it fix your situation? I haven't tried it, but: 1) When I hit my problem symptoms, I hypothesized a probable cause. (desync of crypto state between client and server) 2) The patch addresses the same class of bug. Based on my understanding of the components involved, I think it highly likely the patch will fix it. I do have a server I can test it on, so I'll give it a try. While I'm here, I'll raise one other thing...the code increments the sequence number twice when preparing a send, once for the send, and once for response. My gut tells me that it would be less sloppy to instead increment once for send, and once at the time of receipt...but updating the sequence number at that time might carry an unnecessary performance penalty, and so perhaps that's a valid use of the server's receive window. (I haven't studied the protocol in depth, though, so I might be way off.)
Attachment:
signature.asc
Description: OpenPGP digital signature
