On Sat, 29 Dec 2012 01:24:36 +0100 Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > On Mon, 2012-12-24 at 09:14 -0500, Jeff Layton wrote: > > On Sun, 23 Dec 2012 09:10:34 -0500 > > Jeff Layton <jlayton@xxxxxxxxxx> wrote: > [...] > > > I had a look at the code today and suspect that I know what the problem > > > is. When the kernel goes to send a request, it first signs it and then > > > bumps the sequence numbers that it tracks. If the request doesn't > > > actually make it out onto the wire, like when the task catches a > > > signal, those sequence numbers remain high even though the request > > > didn't go out. > > > > > > Here's an untested patch that might help tell whether this is the > > > case. You may want to try it and see if it does. Note that this fix is > > > a bit of a kludge and is not suitable for merging! > > > > > > A better fix would involve changing when the sequence number gets > > > bumped in the first place. If this patch seems to help things, then > > > I'll look at coding up that up. > [...] > > I was able to reproduce this, and I don't think the above patch will > > fix it (at least not completely). The problem seems to be that the NT > > cancel command is screwing up the sequence numbers. We'll have to do > > some research to figure out why that's occurring. > > Jeff, we got a bug report in Debian which seems to be the same problem: > <http://bugs.debian.org/695492>. Please cc John Darrah and the bug > address as above. > > Ben. > You may want to try this patch. It seems to fix the problem for me, but I think there is probably some more work to do in this area. http://www.spinics.net/lists/linux-cifs/msg07576.html -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
