On Tue, 14 Dec 2010 22:05:53 -0600 Steve French <smfrench@xxxxxxxxx> wrote: > 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.) > mid_q_entries are small. I don't think we'll have much of a problem in practice. But, if you think it's enough of a problem to worry about I can try to do this before the merge window. Assuming I do so, does the rest of the set look ready for merge into 2.6.38? Thanks, -- 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
