1. 05 May, 2020 4 commits
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Weaken rwlock around ramdisk access · 67da413f
      Douglas Gilbert authored
      The design of this driver is to do any ramdisk access on the same thread
      that invoked the queuecommand() call. That is assumed to be user space
      context. The command duration is implemented by setting the delay with a
      high resolution timer. The hr timer's callback may well be in interrupt
      context, but it doesn't touch the ramdisk. So try removing the
      _irqsave()/_irqrestore() portion on the read-write lock that protects
      ramdisk access.
      
      Link: https://lore.kernel.org/r/20200421151424.32668-5-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      67da413f
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Implement VERIFY(10), add VERIFY(16) · c3e2fe92
      Douglas Gilbert authored
      With the addition of the per_host_store option, the ability to check
      whether two different ramdisk images are the same or not becomes
      practical. Prior to this patch VERIFY(10) always returned true (i.e.  the
      SCSI GOOD status) without checking. This option adds support for BYTCHK
      equal to 0, 1 and 3. If the comparison fails, then a sense key of
      MISCOMPARE is returned as per the T10 standards. Also add support for the
      VERIFY(16) command.
      
      Link: https://lore.kernel.org/r/20200421151424.32668-4-dgilbert@interlog.comReviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      c3e2fe92
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Add per_host_store option · 87c715dc
      Douglas Gilbert authored
      The scsi_debug driver has always been restricted to using one ramdisk image
      (or none) for its storage. This means that thousands of scsi_debug devices
      can be created without exhausting the host machine's RAM. The downside is
      that all scsi_debug devices share the same ramdisk image. This option
      changes the way a following write to the add_host parameter (or an add_host
      in the module/driver invocation) operates.  For each new host that is
      created while per_host_store is true, a new store (of dev-size_mb MiB) is
      created and associated with all the LUs that belong to that new host. The
      user (who will need root permissions) needs to take care not to exhaust all
      the machine's available RAM.
      
      One reason for doing this is to check that (partial) disk to disk copies
      based on scsi_debug devices have actually copied accurately. To test this
      the add_host=<n> parameter where <n> is 2 or greater can be used when the
      scsi_debug module is loaded. Let us assume that /dev/sdb and /dev/sg1 are
      the same scsi_debug device, while /dev/sdc and /dev/sg2 are the same
      scsi_debug device. With per_host_store=1 add_host=2 they will have
      different ramdisk images. Then the following pseudocode could be executed
      to check if the sgh_dd copy worked:
      
          dd if=/dev/urandom of=/dev/sdb
          sgh_dd if=/dev/sg1 of=/dev/sg2 [plus option(s) to test]
          cmp /dev/sdb /dev/sdc
      
      If the cmp fails then the copy has failed (or some other mechanism wrote to
      /dev/sdb or /dev/sdc in the interim).
      
      [mkp: use kstrtobool()]
      
      Link: https://lore.kernel.org/r/20200421151424.32668-3-dgilbert@interlog.comSigned-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      87c715dc
    • Douglas Gilbert's avatar
      scsi: scsi_debug: Randomize command completion time · 0c4bc91d
      Douglas Gilbert authored
      Add a new command line option (e.g. random=1) and sysfs attribute that
      causes subsequent command completion times to be between the current
      command delay setting and 0. A uniformly distributed 32 bit, kernel
      provided integer is used for this purpose.
      
      Since the existing 'delay' whose units are jiffies (typically milliseconds)
      and 'ndelay' (units: nanoseconds) options (and sysfs attributes) span a
      range greater than 32 bits, some scaling is required.
      
      The purpose of this patch is to widen the range of testing cases that are
      visited in long running tests. Put simply: rarely struct race conditions
      are more likely to be found when this facility is used.
      
      The default is the previous case in which all command completions were
      roughly equal to (if not, slightly longer) than the value given by the
      'delay' or 'ndelay' settings (or their defaults).  This option's default is
      equivalent to setting 'random=0' .
      
      [mkp: use kstrtobool()]
      
      Link: https://lore.kernel.org/r/20200421151424.32668-2-dgilbert@interlog.comReviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarDouglas Gilbert <dgilbert@interlog.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      0c4bc91d
  2. 30 Apr, 2020 4 commits
  3. 27 Apr, 2020 7 commits
  4. 24 Apr, 2020 25 commits