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

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

[Laurence Oberman]

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. MTIOCGET reports file/block -1 at BOT after reset + MTLOAD

   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.

   Patch 2 records file/block 0 after a successful load when the current
   partition is 0.

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.

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.

For the position test, "ok" on patched kernels 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)

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 | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

[PATCH 1/2] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN

[Laurence Oberman]

A device reset returns the drive's density and block size to their
defaults.  Commit 7081dc75df79 ("scsi: st: Restore some drive settings
after reset") re-applies values changed by the user when the position is
recovered with MTREW, MTSEEK or MTEOM.  MTLOAD and MTRETEN are also
allowed to clear the reset condition and also leave the same medium at
BOT, but they restore nothing.

Because check_tape() reads the drive's block size with MODE SENSE on
every open, the driver silently switches to the drive default after the
reset.  An application that set fixed-block mode with MTSETBLK and
recovers with MTLOAD or MTRETEN keeps writing, but variable-length
blocks, without any error.

Restore the changed density and block size for MTLOAD and MTRETEN as
well.  Both operations 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.  So save the values before the operation, let
check_tape() run first (do_load_unload() already calls it for MTLOAD;
call it after MTRETEN), and then re-apply them.  Retry the restore once
in case a unit attention is still pending.
In immediate mode (MT_ST_NOWAIT) MTRETEN may return before the
retension has finished; do not wait for it there.

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

Reproduced with scsi_debug (which reports a new medium after MTRETEN and
MTLOAD) and with IBM LTO drives on FC (which do not).

Fixes: 7081dc75df79 ("scsi: st: Restore some drive settings after reset")
Assisted-by: Claude sashiko
Signed-off-by: Laurence Oberman <loberman@redhat.com>
---
 drivers/scsi/st.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index f1c3c4946637..0a4263bef9cb 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -3586,6 +3586,23 @@ static long st_common_ioctl(struct scsi_tape *STp, struct st_modedef *STm,
 	return retval;
 }
 
+/*
+ * Re-apply a density and block size that were changed by the user before a
+ * device reset (a negative value means "not changed").  A unit attention
+ * still pending after the operation (e.g. new medium after a load) fails the
+ * first MODE SELECT, so retry each once.  As in the other post-reset restore
+ * path, errors are ignored and one setting failing does not prevent
+ * restoring the other.
+ */
+static void st_restore_changed_settings(struct scsi_tape *STp, int density,
+					int blksize)
+{
+	if (density >= 0 && st_int_ioctl(STp, MTSETDENSITY, density))
+		st_int_ioctl(STp, MTSETDENSITY, density);
+	if (blksize >= 0 && st_int_ioctl(STp, MTSETBLK, blksize))
+		st_int_ioctl(STp, MTSETBLK, blksize);
+}
+
 /* The ioctl command */
 static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 {
@@ -3594,6 +3611,7 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 	int retval = 0;
 	unsigned int blk;
 	bool cmd_mtiocget;
+	int restore_density = -1, restore_blksize = -1;
 	struct scsi_tape *STp = file->private_data;
 	struct st_modedef *STm;
 	struct st_partstat *STps;
@@ -3740,6 +3758,17 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 					st_int_ioctl(STp, MTSETDENSITY, STp->changed_density);
 				if (STp->blksize_changed)
 					st_int_ioctl(STp, MTSETBLK, STp->changed_blksize);
+			} else if (mtc.mt_op == MTLOAD || mtc.mt_op == MTRETEN) {
+				/*
+				 * The same medium ends up at BOT, so the settings
+				 * apply as with MTREW.  The operation may start a
+				 * new session, which clears the "changed" flags:
+				 * save the values and restore them afterwards.
+				 */
+				if (STp->density_changed)
+					restore_density = STp->changed_density;
+				if (STp->blksize_changed)
+					restore_blksize = STp->changed_blksize;
 			}
 		}
 
@@ -3819,6 +3848,9 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 
 		if (mtc.mt_op == MTLOAD) {
 			retval = do_load_unload(STp, file, max(1, mtc.mt_count));
+			if (!retval)
+				st_restore_changed_settings(STp, restore_density,
+							    restore_blksize);
 			goto out;
 		}
 
@@ -3837,6 +3869,19 @@ static long st_ioctl(struct file *file, unsigned int cmd_in, unsigned long arg)
 			retval = st_compression(STp, (mtc.mt_count & 1));
 		else
 			retval = st_int_ioctl(STp, mtc.mt_op, mtc.mt_count);
+		if (!retval && mtc.mt_op == MTRETEN && !STp->immediate &&
+		    (restore_density >= 0 || restore_blksize >= 0)) {
+			/*
+			 * Retension reloads the medium and the drive may
+			 * report a new medium.  Let check_tape() start the new
+			 * session (applying the mode defaults) now, as for
+			 * MTLOAD; otherwise it happens at the next open and
+			 * overrides the restored settings.
+			 */
+			if (check_tape(STp, file) >= 0)
+				st_restore_changed_settings(STp, restore_density,
+							    restore_blksize);
+		}
 		goto out;
 	}
 	if (!STm->defined) {
-- 
2.55.0

[PATCH 2/2] scsi: st: Record the tape position after a successful MTLOAD

[Laurence Oberman]

Commit 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed
after device reset") allows MTLOAD to clear the reset condition because
the tape location is known after MTLOAD.  But the driver does not record
it: reset_state() sets the file and block numbers to -1, and
do_load_unload() leaves them there.  check_tape() sets them to 0 only for
a new session, which requires a new-medium unit attention.  Drives that
do not report one when the medium was already loaded (seen with IBM LTO
drives) keep reporting file/block -1 in MTIOCGET and no BOT, although the
tape is at the beginning.

Set the file and block numbers to 0 after a successful load when the
current partition is 0, where LOAD positions the medium.

Fixes: 0b120edb37dc ("scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset")
Assisted-by: Claude sashiko
Signed-off-by: Laurence Oberman <loberman@redhat.com>
---
 drivers/scsi/st.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index 0a4263bef9cb..8889714122c7 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -2686,6 +2686,14 @@ static int do_load_unload(struct scsi_tape *STp, struct file *filp, int load_cod
 		else {
 			STp->rew_at_close = STp->autorew_dev;
 			retval = check_tape(STp, filp);
+			/*
+			 * LOAD leaves the medium at the beginning of partition
+			 * 0.  check_tape() records that only for a new session;
+			 * without a new-medium unit attention (the medium was
+			 * already loaded) the position would stay unknown.
+			 */
+			if (retval == CHKRES_READY && STp->partition == 0)
+				STp->ps[0].drv_file = STp->ps[0].drv_block = 0;
 			if (retval > 0)
 				retval = 0;
 		}
-- 
2.55.0

Re: [PATCH 2/2] scsi: st: Record the tape position after a successful MTLOAD

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: st: Incomplete state reset in MTLOAD leaves eof active
--

commit bbaf6dbbc22cda3f48df1d40d4f966097f9dac28
Author: Laurence Oberman <loberman@redhat.com>

scsi: st: Record the tape position after a successful MTLOAD

This commit sets the tape file and block numbers to 0 after a successful
MTLOAD when the current partition is 0. This addresses an issue with drives
that do not report a new-medium unit attention when the medium is already
loaded, keeping the position state unknown.

> diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> index 3280ec5702493..02aec1cea2470 100644
> --- a/drivers/scsi/st.c
> +++ b/drivers/scsi/st.c
> @@ -2688,6 +2688,14 @@ static int do_load_unload(struct scsi_tape *STp, struct file *filp, int load_cod
>  		else {
>  			STp->rew_at_close = STp->autorew_dev;
>  			retval = check_tape(STp, filp);
> +			/*
> +			 * LOAD leaves the medium at the beginning of partition
> +			 * 0.  check_tape() records that only for a new session;
> +			 * without a new-medium unit attention (the medium was
> +			 * already loaded) the position would stay unknown.
> +			 */
> +			if (retval == CHKRES_READY && STp->partition == 0)
> +				STp->ps[0].drv_file = STp->ps[0].drv_block = 0;

[Severity: Medium]
Will this leave the EOF and filemark state flags desynchronized?

If a user reads a tape until EOD, setting STps->eof = ST_EOD, and then
issues an MTLOAD, the tape is physically rewound. The patched code in
do_load_unload() resets the file and block numbers to 0 here, but the
STps->eof flag does not appear to be cleared to ST_NOEOF as it would be
for an MTREW command.

If they attempt to read again, won't st_read() check STps->eof >= ST_EOD_1
and abort with -EIO? Does STps->eof also need to be cleared here to ensure
read() operations succeed after an MTLOAD?

>  			if (retval > 0)
>  				retval = 0;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260927131019.4188777-1-loberman@redhat.com?part=2

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

["Kai Mäkisara (Kolumbus)"]

Just a couple of quick notes. I will try to find time to look at the changes more thoroughly
later (as a non-maintainer). (And I am happy to see that improvements are being made.)

> On 27. Sep 2026, at 16.10, Laurence Oberman <loberman@redhat.com> wrote:
> 
> ...

> 1. Changed block size and density are silently lost
> 
> ...

>                                                                               scsi_debug reports a new
>   medium after MTRETEN and MTLOAD; the IBM drives do not.  The series
>   was tested against both behaviours.

This is the only place where scsi_debug deliberately does not follow the standards.
According to the standard, the drive should not report new medium in this case. This
deviation was made to enable testing of this condition somehow. (scsi_debug does
not support insertion of a new tape.)

Otherwise scsi_debug should follow the standard as far as features have been
implemented. But there may be bugs outside of what has been tested. So, if
a real drive and scsi_debug behave differently, scsi_debug maybe wrong.
However, in some cases, alternative behaviours are defined in the standard.
scsi_debug has implemented one and it may not be the one the drive is
implementing.

Thanks, Kai