[PATCH v3 0/4] scsi: st: Restore drive settings and state after reset and MTLOAD

[Laurence Oberman <loberman@redhat.com>]

After a device reset st blocks tape access until one of MTREW, MTOFFL,
MTLOAD, MTRETEN, MTERASE, MTSEEK or MTEOM clears the reset condition.
Testing the reset handling on scsi_debug and on IBM LTO drives found that
several settings and parts of the driver state do not survive the reset
or an MTLOAD.

1. Changed block size and density are lost after MTLOAD or MTRETEN

   A reset returns the drive's block size and density to their defaults.
   Commit 7081dc75df79 ("scsi: st: Restore some drive settings after
   reset") re-applies the values set by the user, but only for MTREW,
   MTSEEK and MTEOM.  Because check_tape() reads the drive's block size
   with MODE SENSE on every open, the driver follows the drive back to
   its default after the reset.  An application that set fixed-block
   mode with MTSETBLK and recovers with MTLOAD or MTRETEN keeps writing
   without any error, but in variable-length blocks.

   Patch 1 restores the changed settings for MTLOAD and MTRETEN as well.
   Both may make the drive report a new medium, and the new session
   started by check_tape() clears the "changed" flags and applies the
   mode defaults.  The values are therefore saved before the operation
   and re-applied after check_tape() has run.  scsi_debug reports a new
   medium after MTRETEN and MTLOAD; the IBM drives do not.  The series
   was tested against both behaviours.

2. Tape state is not reset after MTLOAD of an already loaded medium

   A LOAD positions the medium at the beginning of partition 0.
   check_tape() records that only when it starts a new session, which
   requires a new-medium unit attention.  Drives that do not report one
   for an already loaded cartridge (IBM LTO) are left with the state from
   before the load:

   - After a reset, MTIOCGET keeps reporting file/block -1 and no BOT,
     although commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to
     ioctls allowed after device reset") allows MTLOAD because the tape
     location is known after it.
   - After reading to EOD, a read following MTLOAD fails with EIO.
   - If partition 1 was selected, st still records partition 1, so a
     later MTSETPART 1 is not performed and I/O goes to partition 0.

   Patch 2 sets the partition to 0, the position to BOT and resets the
   EOF state after a successful load, as the new-session path in
   check_tape() and MTREW do.

3. The drive buffering mode is lost after a reset

   A reset also returns the drive's buffered mode to its default, and
   check_tape() reads it back on every open, so a mode set with
   MTSETDRVBUFFER is lost - with every recovery operation, including
   MTREW.  Unlike density and block size there was no "changed" state to
   restore it from.  Patch 3 records the value set with MTSETDRVBUFFER
   and restores it in both restore paths, before density and block size.

4. The door is not locked again after a reset

   With auto-lock, st locks the door at the first read or write.  A reset
   clears the drive's medium removal prevention, but st kept its locked
   state and never locked the door again.  Patch 4 marks the door
   unlocked when a reset is recognized, so the next access locks it.

MTOFFL is deliberately not changed: the medium is unloaded, and a
different one may be loaded next, for which the mode defaults should
apply.

Immediate mode: with MT_ST_NOWAIT, MTRETEN returns before the
retension completes, so patch 1 does not restore the settings there
rather than waiting for the drive.

The SCSI tape driver is currently marked Orphan in MAINTAINERS.

Testing (v7.3-rc2, scsi_debug and IBM LTO drives on FC):

Block size after reset + recovery (patch 1):

                            R04.load       R04.retension  R04.offline
unpatched:
  scsi_debug                discarded      discarded      discarded
  IBM ULTRIUM-TD5 (LTO-5)   discarded      discarded      discarded
  IBM ULT3580-TDA           discarded      discarded      discarded
patched:
  scsi_debug                restored       restored       discarded (*)
  IBM ULTRIUM-TD5 (LTO-5)   restored       restored       discarded (*)
  IBM ULT3580-TDA           restored       restored       discarded (*)

(*) unchanged by design, see above.

State after MTLOAD (patch 2):

  R03.load: position after reset + MTLOAD
    IBM LTO-5 and ULT3580-TDA  unpatched: MTIOCGET -1:-1    v3: ok (0:0)
    scsi_debug                 unpatched and v3: ok (new session)
  B09: read after MTLOAD at EOD, no reset
    IBM ULT3580-TDA            v1: read() fails with EIO    v2, v3: ok
    scsi_debug                 v1, v2, v3: ok (new session)
  X04: MTLOAD while in partition 1, then MTSETPART 1 and read
    IBM ULTRIUM-TD5 (LTO-5)    v2: MTIOCGET still reports partition 1,
                                   MTSETPART 1 not performed, read in
                                   partition 0 fails with EIO
                               v3: ok
    scsi_debug                 v2, v3: ok (new session)

Drive buffering mode after reset (patch 3), read from the drive with
MODE SENSE through the sg node, mode 0 set with MTSETDRVBUFFER:

  R15: reset + MTREW / MTLOAD / MTRETEN
    IBM ULTRIUM-TD5 (LTO-5)    patches 1-2: drive back in mode 1
                               v3:          mode 0 restored
    scsi_debug                 does not implement buffered mode

Door lock after reset (patch 4), auto-lock on, same open file:

  R16: read (locks), reset, recover, read
    IBM ULTRIUM-TD5 (LTO-5)    patches 1-2: door not locked again
                               v3:          locked again
    scsi_debug                 v3:          locked again

For the position tests, "ok" means that MTIOCPOS returns 0 and the
first block read without repositioning is block 0 of file 0; it is not
based on MTIOCGET alone.  The restore after MTREW/MTSEEK/MTEOM from
7081dc75df79 is unaffected on all devices.  Every test ends with a
byte-exact read-back of the whole tape.

The tests are part of a tape validation harness (reset detection, the
blocked-operation matrix, recovery operations, interrupted I/O, SCSI EH
via scsi_debug error injection); B09, X04, R15 and R16 were added for
the review comments on v1 and v2:
https://gitlab.com/loberman/tapetest (developed with AI assistance)

Changes since v2:
- Patch 2: after a successful load, set the partition to 0 for all
  partitions, not only when the current partition is 0 (Kai Mäkisara).
- New patch 3: restore the drive buffering mode after reset (Kai
  Mäkisara).
- New patch 4: relock the door after reset (Kai Mäkisara).
- Patch 1: unchanged.

Changes since v1:
- Patch 2: also reset the EOF state (and at_sm, last_block_valid) after
  the load, as MTREW does (found by Sashiko).

v2: https://marc.info/?l=linux-scsi&m=179060186958028&w=2
v1: https://marc.info/?l=linux-scsi&m=179051462299046&w=2

Laurence Oberman (4):
  scsi: st: Restore changed drive settings after reset also for MTLOAD
    and MTRETEN
  scsi: st: Record the tape position after a successful MTLOAD
  scsi: st: Restore the drive buffering mode after reset
  scsi: st: Relock the door after a reset

 drivers/scsi/st.c | 83 +++++++++++++++++++++++++++++++++++++++++++++--
 drivers/scsi/st.h |  2 ++
 2 files changed, 82 insertions(+), 3 deletions(-)

-- 
2.55.0