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. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Attachment:
signature.asc
Description: This is a digitally signed message part
