From patchwork Wed Apr 11 14:56:33 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andy Whitcroft X-Patchwork-Id: 151808 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id AC39BB7055 for ; Thu, 12 Apr 2012 00:56:52 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SHyyM-0007sr-9u; Wed, 11 Apr 2012 14:56:38 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1SHyyJ-0007sY-Dx for kernel-team@lists.ubuntu.com; Wed, 11 Apr 2012 14:56:35 +0000 Received: from 79-78-218-124.dynamic.dsl.as9105.com ([79.78.218.124] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SHyyJ-0003Yc-0q; Wed, 11 Apr 2012 14:56:35 +0000 From: Andy Whitcroft To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/1] UBUNTU: SAUCE: hv_storvsc: Account for in-transit packets in the RESET path Date: Wed, 11 Apr 2012 15:56:33 +0100 Message-Id: <1334156193-12107-2-git-send-email-apw@canonical.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1334156193-12107-1-git-send-email-apw@canonical.com> References: <1334156193-12107-1-git-send-email-apw@canonical.com> Cc: Andy Whitcroft X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com From: "K. Y. Srinivasan" Properly account for I/O in transit before returning from the RESET call. In the absense of this patch we could have a situation where the host may respond to a command that was issued prior to the issuance of the RESET command at some arbitrary time after responding to the RESET command. Currently, the host does not do anything with the RESET command and so it is ok to wait for the in-transit I/O to be accounted for. If the host side sematics changes, we will have to revisit this. Signed-off-by: K. Y. Srinivasan BugLink: http://bugs.launchpad.net/bugs/978394 Signed-off-by: Andy Whitcroft --- drivers/scsi/storvsc_drv.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 5848a97..af3383f 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1223,7 +1223,12 @@ static int storvsc_host_reset_handler(struct scsi_cmnd *scmnd) /* * At this point, all outstanding requests in the adapter * should have been flushed out and return to us + * There is a potential race here where the host may be in + * the process of responding when we return from here. + * Just wait for all in-transit packets to be accounted for + * before we return from here. */ + storvsc_wait_to_drain(stor_device); return SUCCESS; }