linux-toradex.git/drivers/scsi/st.c, branch v6.13-rc7

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2024-11-26T02:50:55+00:00

Pull SCSI updates from James Bottomley:
 "Updates to the usual drivers (ufs, lpfc, hisi_sas, st).

  Amazingly enough, no core changes with the biggest set of driver
  changes being ufs (which conflicted with it's own fixes a bit, hence
  the merges) and the rest being minor fixes and updates"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (97 commits)
  scsi: st: New session only when Unit Attention for new tape
  scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset
  scsi: st: Don't modify unknown block number in MTIOCGET
  scsi: ufs: core: Restore SM8650 support
  scsi: sun3: Mark driver struct with __refdata to prevent section mismatch
  scsi: sg: Enable runtime power management
  scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()
  scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()
  scsi: fusion: Remove unused variable 'rc'
  scsi: bfa: Fix use-after-free in bfad_im_module_exit()
  scsi: esas2r: Remove unused esas2r_build_cli_req()
  scsi: target: Fix incorrect function name in pscsi_create_type_disk()
  scsi: ufs: Replace deprecated PCI functions
  scsi: Switch back to struct platform_driver::remove()
  scsi: pm8001: Increase request sg length to support 4MiB requests
  scsi: pm8001: Initialize devices in pm8001_alloc_dev()
  scsi: pm8001: Use module param to set pcs event log severity
  scsi: ufs: ufs-mediatek: Configure individual LU queue flags
  scsi: MAINTAINERS: Update UFS Exynos entry
  scsi: lpfc: Copyright updates for 14.4.0.6 patches
  ...

scsi: st: New session only when Unit Attention for new tape

2024-11-07T02:18:16+00:00

Currently the code starts new tape session when any Unit Attention
(UA) is seen when opening the device. This leads to incorrectly
clearing pos_unknown when the UA is for reset. Set new session only
when the UA is for a new tape.

Signed-off-by: Kai Mäkisara 
Link: https://lore.kernel.org/r/20241106095723.63254-4-Kai.Makisara@kolumbus.fi
Reviewed-by: John Meneghini 
Tested-by: John Meneghini 
Signed-off-by: Martin K. Petersen

scsi: st: Add MTIOCGET and MTLOAD to ioctls allowed after device reset

2024-11-07T02:18:15+00:00

Most drives rewind the tape when the device is reset. Reading and writing
are not allowed until something is done to make the tape position match the
user's expectation (e.g., rewind the tape). Add MTIOCGET and MTLOAD to
operations allowed after reset. MTIOCGET is modified to not touch the tape
if pos_unknown is non-zero. The tape location is known after MTLOAD.

Signed-off-by: Kai Mäkisara 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14
Link: https://lore.kernel.org/r/20241106095723.63254-3-Kai.Makisara@kolumbus.fi
Reviewed-by: John Meneghini 
Tested-by: John Meneghini 
Signed-off-by: Martin K. Petersen

scsi: st: Don't modify unknown block number in MTIOCGET

2024-11-07T02:18:15+00:00

Struct mtget field mt_blkno -1 means it is unknown. Don't add anything to
it.

Signed-off-by: Kai Mäkisara 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=219419#c14
Link: https://lore.kernel.org/r/20241106095723.63254-2-Kai.Makisara@kolumbus.fi
Reviewed-by: John Meneghini 
Tested-by: John Meneghini 
Signed-off-by: Martin K. Petersen

move asm/unaligned.h to linux/unaligned.h

2024-10-02T21:23:23+00:00

asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.

auto-generated by the following:

for i in `git grep -l -w asm/unaligned.h`; do
	sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
	sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

scsi: st: Fix input/output error on empty drive reset

2024-09-13T00:07:11+00:00

A previous change was introduced to prevent data loss during a power-on
reset when a tape is present inside the drive. This commit set the
"pos_unknown" flag to true to avoid operations that could compromise data
by performing actions from an untracked position. The relevant change is
commit 9604eea5bd3a ("scsi: st: Add third party poweron reset handling")

As a consequence of this change, a new issue has surfaced: the driver now
returns an "Input/output error" even for empty drives when the drive, host,
or bus is reset. This issue stems from the "flush_buffer" function, which
first checks whether the "pos_unknown" flag is set. If the flag is set, the
user will encounter an "Input/output error" until the tape position is
known again. This behavior differs from the previous implementation, where
empty drives were not affected at system start up time, allowing tape
software to send commands to the driver to retrieve the drive's status and
other information.

The current behavior prioritizes the "pos_unknown" flag over the
"ST_NO_TAPE" status, leading to issues for software that detects drives
during system startup. This software will receive an "Input/output error"
until a tape is loaded and its position is known.

To resolve this, the "ST_NO_TAPE" status should take priority when the
drive is empty, allowing communication with the drive following a power-on
reset. At the same time, the change should continue to protect data by
maintaining the "pos_unknown" flag when the drive contains a tape and its
position is unknown.

Signed-off-by: Rafael Rocha 
Link: https://lore.kernel.org/r/20240905173921.10944-1-rrochavi@fnal.gov
Fixes: 9604eea5bd3a ("scsi: st: Add third party poweron reset handling")
Acked-by: Kai Mäkisara 
Signed-off-by: Martin K. Petersen

scsi: st: Drop driver owner initialization

2024-04-06T00:58:25+00:00

Core in scsi_register_driver() already sets the .owner, so driver does not
need to.

Signed-off-by: Krzysztof Kozlowski 
Link: https://lore.kernel.org/r/20240328-b4-module-owner-scsi-v1-5-c86cb4f6e91c@linaro.org
Signed-off-by: Martin K. Petersen

scsi: st: Make st_sysfs_class constant

2024-03-10T22:15:49+00:00

Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the st_sysfs_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Cc: Greg Kroah-Hartman 
Suggested-by: Greg Kroah-Hartman 
Signed-off-by: Ricardo B. Marliere 
Link: https://lore.kernel.org/r/20240302-class_cleanup-scsi-v1-5-b9096b990e27@marliere.net
Signed-off-by: Martin K. Petersen

scsi: st: Add third party poweron reset handling

2023-08-25T02:16:28+00:00

Many tape devices will automatically rewind following a poweron/reset.
This can result in data loss as other operations in the driver can write to
the tape when the position is unknown. E.g. MTEOM can write a filemark at
the beginning of the tape. This patch adds code to detect poweron/reset
unit attentions and prevents the driver from writing to the tape when the
position could be unknown.

Customer reported problem description:

We have experienced an issue with the SCSI tape driver (st) which has led
to data loss for us on two separate occasions in production, as well as in
a third case in which we were able to reproduce the failure in our test
environment.

The tape device involved is an Amazon Tape Gateway, a virtual tape library
(VTL) appliance which presents as a series of iSCSI targets (multiple tape
drives and a changer) and is backed by storage in Amazon S3. The problem is
a general one and not limited to any particular SCSI transport or tape
device, though the nature of both iSCSI and the VTL make data loss somewhat
more likely with this combination than with a physical tape drive.

The observed behavior occurs when an error causes the VTL tape gateway
process (on the appliance) to crash and restart. This interrupts the iSCSI
TCP connections and, when it occurs during a write, causes the write to
fail with EIO. However, we then find that the virtual tape in question is
now completely blank. We raised this issue with AWS support, thinking this
must be a bug in the VTL appliance, but that turns out not to be the case.

Per AWS support, when the gateway crashes in this manner, its notion of the
current tape position is reset to the beginning of the tape. It also sets a
unit attention condition, such that the next request results in a CHECK
CONDITION status with sense key UNIT ATTENTION and asc/ascq indicating a
device reset. According to their logs the next command being sent is WRITE
FILEMARK, which results in writing an FM at the beginning of the tape,
effectively discarding its contents.

In fact, once the write fails with EIO, our software attempts to recover by
rewinding and repositioning the tape, then resuming operation. If this
fails, it attempts to rewind and reposition again, write a marker at the
end of the tape, and then unmount. It does not under any circumstances
write either data or filemarks without having successfully positioned the
tape to a known point.

What actually happens is that, since the last operation was a write, the
kernel executes an implied MTWEOF operation (which translate to a Write
Filemarks command) before the rewind that was actually requested. This
seems not entirely unreasonable, provided the tape position is known.
However, once this request fails (due to the unit attention condition), our
next rewind attempt also triggers an implied MTWEOF, which does _not_ fail
(the unit attention condition persists only until the initiator has been
notified); this is the command that unexpectedly erases the tape.

Our analysis is that the st driver is in fact completely ignoring the UNIT
ATTENTION and associated reset notification from the device. This is not a
condition that can be detected in the transport or mid-layer, as it occurs
entirely within the target and is reported only via the UNIT ATTENTION
sense key. The upper driver (i.e. st) needs to detect this indication and
reset its internal model of the device to an unknown state.

Suggested-by: Jeffrey Hutzelman 
Signed-off-by: John Meneghini 
Link: https://lore.kernel.org/r/20230822181413.1210647-1-jmeneghi@redhat.com
Acked-by: Kai Mäkisara 
Signed-off-by: Martin K. Petersen

scsi: replace the fmode_t argument to scsi_ioctl with a simple bool

2023-06-12T14:04:04+00:00

Instead of passing a fmode_t and only checking it for FMODE_WRITE, pass
a bool open_for_write to prepare for callers that won't have the fmode_t.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Martin K. Petersen 
Reviewed-by: Hannes Reinecke 
Acked-by: Christian Brauner 
Link: https://lore.kernel.org/r/20230608110258.189493-20-hch@lst.de
Signed-off-by: Jens Axboe