All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Laurence Oberman" <loberman@redhat.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 2/4] scsi: st: Record the tape position after a successful MTLOAD
Date: Tue, 29 Sep 2026 17:41:41 +0000	[thread overview]
Message-ID: <20260929174142.172051F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260929171813.844733-3-loberman@redhat.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] scsi: st: data corruption via rogue filemarks after MTLOAD
--

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

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

This commit records the tape partition, position, and EOF state after a
successful MTLOAD, similar to how check_tape() does for a new session.
This fixes an issue where the driver would incorrectly report file/block
as -1 because drives didn't report a new-medium unit attention when
already loaded.

> diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
> index 0a4263bef9cbb..e5b2e2d4872d3 100644
> --- a/drivers/scsi/st.c
> +++ b/drivers/scsi/st.c
> @@ -2686,6 +2686,22 @@ 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 partition, position and EOF state
> +			 * would be left as before the load.  Set them as a new
> +			 * session and MTREW do.
> +			 */
> +			if (retval == CHKRES_READY) {
> +				STp->partition = STp->new_partition = 0;
> +				STps = &(STp->ps[0]);
> +				STps->drv_file = STps->drv_block = 0;
> +				STps->eof = ST_NOEOF;
> +				STps->at_sm = 0;
> +				STps->last_block_valid = 0;

[Severity: High]
Does this code risk data corruption by omitting a reset of the rw state?

If a user writes data to partition 0 (setting ps[0].rw = ST_WRITING), issues
MTSETPART 1, and then switches to partition 1, ps[0].rw remains ST_WRITING.

If the user then issues MTLOAD, the ioctl clears the rw state for the current
partition (ps[1]), but do_load_unload() then forces STp->partition = 0 without
clearing ps[0].rw.

Upon closing the device, st_flush() would see ps[0].rw == ST_WRITING and
unconditionally execute WRITE_FILEMARKS at the beginning of the tape (BOT),
overwriting and destroying previously recorded data.

Should STps->rw = ST_IDLE; be added to this block to prevent rogue filemark
writes at BOT?

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

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

  reply	other threads:[~2026-09-29 17:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-29 17:18 [PATCH v3 0/4] scsi: st: Restore drive settings and state after reset and MTLOAD Laurence Oberman
2026-09-29 17:18 ` [PATCH v3 1/4] scsi: st: Restore changed drive settings after reset also for MTLOAD and MTRETEN Laurence Oberman
2026-09-29 17:33   ` sashiko-bot
2026-09-29 17:45     ` Laurence Oberman
2026-09-29 17:18 ` [PATCH v3 2/4] scsi: st: Record the tape position after a successful MTLOAD Laurence Oberman
2026-09-29 17:41   ` sashiko-bot [this message]
2026-09-29 18:16     ` Laurence Oberman
2026-09-29 17:18 ` [PATCH v3 3/4] scsi: st: Restore the drive buffering mode after reset Laurence Oberman
2026-09-29 17:18 ` [PATCH v3 4/4] scsi: st: Relock the door after a reset Laurence Oberman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260929174142.172051F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.