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

[sashiko-bot@kernel.org]

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