On 12/27/2010 07:59 AM, Jeff Layton wrote: > Currently, when a request is cancelled via signal, we delete the mid > immediately. If the request was already transmitted however, the client > is still likely to receive a response. When it does, it won't recognize > it however and will pop a printk. > > It's also a little dangerous to just delete the mid entry like this. We > may end up reusing that mid. If we do then we could potentially get the > response from the first request confused with the later one. > > Prevent the reuse of mids by marking them as cancelled and keeping them > on the pending_mid_q list. If the reply comes in, we'll delete it from > the list then. If it never comes, then we'll delete it at reconnect > or when cifsd comes down. > > Reviewed-by: Pavel Shilovsky <piastryyy@xxxxxxxxx> > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > --- > fs/cifs/transport.c | 43 ++++++++++++++++++++++++++++++++++++------- > 1 files changed, 36 insertions(+), 7 deletions(-) > Looks good to me. Reviewed-by: Suresh Jayaraman <sjayaraman@xxxxxxx> -- 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
