Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Apr 2018 03:06:05 +0000 (UTC)
From:      Dexuan Cui <dexuan@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org
Subject:   svn commit: r332903 - stable/11/sys/dev/hyperv/storvsc
Message-ID:  <201804240306.w3O365pm006301@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: dexuan
Date: Tue Apr 24 03:06:05 2018
New Revision: 332903
URL: https://svnweb.freebsd.org/changeset/base/332903

Log:
  MFC: 332385
  
  r332385:
      hyperv/storvsc: storvsc_io_done(): do not use CAM_SEL_TIMEOUT
  
      CAM_SEL_TIMEOUT was introduced in
      https://reviews.freebsd.org/D7521 (r304251), which claimed:
  
      "VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those
      invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan
      for LUN number higher than 7."
  
      But it turns out this is not correct:
  
      I think what really filters the invalid LUNs in r304251 is that:
      before r304251, we could set the CAM_REQ_CMP without checking
      vm_srb->srb_status at all:
      ccb->ccb_h.status |= CAM_REQ_CMP.
  
      r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly,
      so the invalid LUNs are filtered.
  
      I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT
      with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be
      filtered, and I successfully hot-added and hot-removed 8 disks to/from
      the VM without any issue.
  
      CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error():
      For a selection timeout, we consider all of the LUNs on
      the target to be gone. If the status is CAM_DEV_NOT_THERE,
      then we only get rid of the device(s) specified by the
      path in the original CCB.
  
      This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires
      3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns
      CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: this
      is the bug I reported recently:
      https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226583
  
      PR:     226583
      Reviewed by:    mav
      Sponsored by:   Microsoft
      Differential Revision:  https://reviews.freebsd.org/D14690

Modified:
  stable/11/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c
==============================================================================
--- stable/11/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c	Tue Apr 24 01:22:57 2018	(r332902)
+++ stable/11/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c	Tue Apr 24 03:06:05 2018	(r332903)
@@ -2172,20 +2172,7 @@ storvsc_io_done(struct hv_storvsc_request *reqp)
 					    scsi_op_desc(cmd->opcode, NULL));
 				}
 			}
-
-			/*
-			 * XXX For a selection timeout, all of the LUNs
-			 * on the target will be gone.  It works for SCSI
-			 * disks, but does not work for IDE disks.
-			 *
-			 * For CAM_DEV_NOT_THERE, CAM will only get
-			 * rid of the device(s) specified by the path.
-			 */
-			if (storvsc_get_storage_type(sc->hs_dev) ==
-			    DRIVER_STORVSC)
-				ccb->ccb_h.status |= CAM_SEL_TIMEOUT;
-			else
-				ccb->ccb_h.status |= CAM_DEV_NOT_THERE;
+			ccb->ccb_h.status |= CAM_DEV_NOT_THERE;
 		} else {
 			ccb->ccb_h.status |= CAM_REQ_CMP;
 		}



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201804240306.w3O365pm006301>