On Tue, Dec 14, 2010 at 5:18 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > 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. The logical problem is that certain operations can take many minutes or hours (and those are precisely those which might be ctl-c) so there is a very real possibility that without issuing cancels we could exhaust resources (ctl-c, reissue, ctl-c reissue etc.) -- Thanks, Steve -- 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
