[PATCH v2 0/2] scsi: st: Fix drive settings and position after reset recovery with MTLOAD/MTRETEN

[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 two
problems when the condition is cleared with MTLOAD or MTRETEN.

1. Changed block size and density are silently lost

   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

   Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls
   allowed after device reset") allows MTLOAD because the tape location
   is known after it, but the position is not recorded:
   reset_state() sets -1/-1, and do_load_unload() leaves it there unless
   check_tape() starts a new session.  With drives that do not report a
   new medium for an already loaded cartridge (IBM LTO), MTIOCGET keeps
   reporting -1/-1 and no BOT.  Without a reset, the EOF state is also
   left as it was: after reading to EOD, a read following MTLOAD fails
   with EIO although the tape is at BOT.

   Patch 2 sets the position to BOT and resets the EOF state after a
   successful load when the current partition is 0, as MTREW does.

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.  Kai is
Cc'ed as the author of the reset handling these patches build on.

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

                            R03.load       R04.load      R04.retension  R04.offline
                            (pos. after    (MTSETBLK     (MTSETBLK      (MTSETBLK
                             reset+LOAD)    after LOAD)   after RETEN)   after OFFL)
unpatched:
  scsi_debug                ok (0:0)       discarded     discarded      discarded
  IBM ULTRIUM-TD5 (LTO-5)   -1:-1          discarded     discarded      discarded
  IBM ULT3580-TDA           -1:-1          discarded     discarded      discarded
patched:
  scsi_debug (2 hosts)      ok             restored      restored       discarded (*)
  IBM ULTRIUM-TD5 (LTO-5)   ok             restored      restored       discarded (*)
  IBM ULT3580-TDA           ok             restored      restored       discarded (*)

(*) unchanged by design, see above.

MTLOAD of an already loaded tape at EOD, no reset (B09: read after load):

  IBM ULT3580-TDA   v1: read() fails with EIO   v2: ok
  scsi_debug        v1: ok (new session)        v2: ok

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):
https://gitlab.com/loberman/tapetest (developed with AI assistance)

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 retested on scsi_debug
  and IBM ULT3580-TDA.
- Patch 1: unchanged.

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

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

 drivers/scsi/st.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

-- 
2.55.0