On Tue, 14 Dec 2010 16:22:01 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > On Tue, Dec 14, 2010 at 3:44 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Tue, 14 Dec 2010 15:33:48 -0600 > > Steve French <smfrench@xxxxxxxxx> wrote: > > > >> Why wouldn't we issue SMB NTCancel on these? That way we only have to > >> wait until the timeout for the NTCancel (at worst) and can't leak midq > >> entries. > >> > > > > I suppose we could, but... > > > > a) windows doesn't do it > > Windows does issue cancel requests ... even if not for exactly the same case > Hmm...maybe, but when I asked MS about timeout behavior, Edgar said this: 2) If it returns an error to the application, does the client send a SMB_COM_NT_CANCEL to cancel the outstanding request? Answer: The client will not send a CANCEL request on any outstanding request; it simply tears down the connection after the session times out. ...he may have been talking about timeouts specifically however and not about NT cancel commands in general. Still, I'm a little leery of doing this. It adds complexity to an already very complex codepath. It's also not going to be necessary in most cases. Well behaved servers eventually send a reply of some sort. A server that doesn't is broken. A MID that hangs around until reconnect or unmount is probably the least of your worries in that situation. But in principle, we could do it. There is a send_nt_cancel() command in the code already and we could call it from this codepath. It'll be tricky however as we'll have a signal pending and that affects kernel_sendmsg behavior. There's also the problem that we'll potentially block while trying to send the cancel, which could make it so that you stall userspace out while trying to kill off the process. Not ideal. Maybe we'll need to send the cancel from another context entirely? In any case, I'd really prefer to not do that in the context of this set. It requires some careful thought about how to do it right, and adds complexity that I don't think is needed at this point in time. -- 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
