linux-stable.git/drivers/s390, branch linux-6.3.y

s390/cio: unregister device when the only path is gone

2023-06-28T09:14:20+00:00

[ Upstream commit 89c0c62e947a01e7a36b54582fd9c9e346170255 ]

Currently, if the device is offline and all the channel paths are
either configured or varied offline, the associated subchannel gets
unregistered. Don't unregister the subchannel, instead unregister
offline device.

Signed-off-by: Vineeth Vijayan 
Reviewed-by: Peter Oberparleiter 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/ism: Fix trying to free already-freed IRQ by repeated ism_dev_exit()

2023-06-21T14:02:10+00:00

commit 78d0f94902afce8ec2c7a60f600cc0e3729d7412 upstream.

This patch prevents the system from crashing when unloading the ISM module.

How to reproduce: Attach an ISM device and execute 'rmmod ism'.

Error-Log:
- Trying to free already-free IRQ 0
- WARNING: CPU: 1 PID: 966 at kernel/irq/manage.c:1890 free_irq+0x140/0x540

After calling ism_dev_exit() for each ISM device in the exit routine,
pci_unregister_driver() will execute ism_remove() for each ISM device.
Because ism_remove() also calls ism_dev_exit(),
free_irq(pci_irq_vector(pdev, 0), ism) is called twice for each ISM
device. This results in a crash with the error
'Trying to free already-free IRQ'.

In the exit routine, it is enough to call pci_unregister_driver()
because it ensures that ism_dev_exit() is called once per
ISM device.

Cc:  # 6.3+
Fixes: 89e7d2ba61b7 ("net/ism: Add new API for client registration")
Reviewed-by: Niklas Schnelle 
Signed-off-by: Julian Ruess 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

s390/dasd: Use correct lock while counting channel queue length

2023-06-14T09:16:57+00:00

commit ccc45cb4e7271c74dbb27776ae8f73d84557f5c6 upstream.

The lock around counting the channel queue length in the BIODASDINFO
ioctl was incorrectly changed to the dasd_block->queue_lock with commit
583d6535cb9d ("dasd: remove dead code"). This can lead to endless list
iterations and a subsequent crash.

The queue_lock is supposed to be used only for queue lists belonging to
dasd_block. For dasd_device related queue lists the ccwdev lock must be
used.

Fix the mentioned issues by correctly using the ccwdev lock instead of
the queue lock.

Fixes: 583d6535cb9d ("dasd: remove dead code")
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Jan Höppner 
Reviewed-by: Stefan Haberland 
Signed-off-by: Stefan Haberland 
Link: https://lore.kernel.org/r/20230609153750.1258763-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/pkey: zeroize key blobs

2023-06-09T08:48:06+00:00

[ Upstream commit 844cf829e5f33e00b279230470c8c93b58b8c16f ]

Key blobs for the IOCTLs PKEY_KBLOB2PROTK[23] may contain clear key
material. Zeroize the copies of these keys in kernel memory after
creating the protected key.

Reviewed-by: Harald Freudenberger 
Signed-off-by: Holger Dengler 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/qdio: fix do_sqbs() inline assembly constraint

2023-05-24T16:30:24+00:00

commit 2862a2fdfae875888e3c1c3634e3422e01d98147 upstream.

Use "a" constraint instead of "d" constraint to pass the state parameter to
the do_sqbs() inline assembly. This prevents that general purpose register
zero is used for the state parameter.

If the compiler would select general purpose register zero this would be
problematic for the used instruction in rsy format: the register used for
the state parameter is a base register. If the base register is general
purpose register zero the contents of the register are unexpectedly ignored
when the instruction is executed.

This only applies to z/VM guests using QIOASSIST with dedicated (pass through)
QDIO-based devices such as FCP [zfcp driver] as well as real OSA or
HiperSockets [qeth driver].

A possible symptom for this case using zfcp is the following repeating kernel
message pattern:

zfcp : A QDIO problem occurred
zfcp : A QDIO problem occurred
zfcp : qdio: ZFCP on SC  using AI:1 QEBSM:1 PRI:1 TDD:1 SIGA: W
zfcp : A QDIO problem occurred
zfcp : A QDIO problem occurred

Each of the qdio problem message can be accompanied by the following entries
for the affected subchannel  in
/sys/kernel/debug/s390dbf/qdio_error/hex_ascii for zfcp or qeth:

 ccq: 69....
 SQBS ERROR.

Reviewed-by: Benjamin Block 
Cc: Steffen Maier 
Fixes: 8129ee164267 ("[PATCH] s390: qdio V=V pass-through")
Cc: 
Signed-off-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Greg Kroah-Hartman

s390/dasd: fix command reject error on ESE devices

2023-05-24T16:30:24+00:00

commit c99bff34290f1b994073557b754aff86e4c7b22e upstream.

Formatting a thin-provisioned (ESE) device that is part of a PPRC copy
relation might fail with the following error:

dasd-eckd 0.0.f500: An error occurred in the DASD device driver, reason=09
[...]
24 Byte: 0 MSG 4, no MSGb to SYSOP

During format of an ESE disk the Release Allocated Space command is used.
A bit in the payload of the command is set that is not allowed to be set
for devices in a copy relation. This bit is set to allow the partial
release of an extent.

Check for the existence of a copy relation before setting the respective
bit.

Fixes: 91dc4a197569 ("s390/dasd: Add new ioctl to release space")
Cc: stable@kernel.org # 5.3+
Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Link: https://lore.kernel.org/r/20230519102340.3854819-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/cio: include subchannels without devices also for evaluation

2023-05-24T16:30:16+00:00

[ Upstream commit b1b0d5aec1cf9f9a900a14964f869c68688d923e ]

Currently when the new channel-path is enabled, we do evaluation only
on the subchannels with a device connected on it. This is because,
in the past, if the device in the subchannel is not working or not
available, we used to unregister the subchannels. But, from the 'commit
2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")'
we allow subchannels with or without an active device connected
on it. So, when we do the io_subchannel_verify, make sure that,
we are evaluating the subchannels without any device too.

Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
Reported-by: Boris Fiuczynski 
Signed-off-by: Vineeth Vijayan 
Reviewed-by: Peter Oberparleiter 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Sasha Levin

s390/dasd: fix hanging blockdevice after request requeue

2023-05-11T14:17:37+00:00

commit d8898ee50edecacdf0141f26fd90acf43d7e9cd7 upstream.

The DASD driver does not kick the requeue list when requeuing IO requests
to the blocklayer. This might lead to hanging blockdevice when there is
no other trigger for this.

Fix by automatically kick the requeue list when requeuing DASD requests
to the blocklayer.

Fixes: e443343e509a ("s390/dasd: blk-mq conversion")
CC: stable@vger.kernel.org # 4.14+
Signed-off-by: Stefan Haberland 
Reviewed-by: Jan Hoeppner 
Reviewed-by: Halil Pasic 
Link: https://lore.kernel.org/r/20230405142017.2446986-8-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/vfio-ap: fix memory leak in vfio_ap device driver

2023-03-27T15:23:08+00:00

The device release callback function invoked to release the matrix device
uses the dev_get_drvdata(device *dev) function to retrieve the
pointer to the vfio_matrix_dev object in order to free its storage. The
problem is, this object is not stored as drvdata with the device; since the
kfree function will accept a NULL pointer, the memory for the
vfio_matrix_dev object is never freed.

Since the device being released is contained within the vfio_matrix_dev
object, the container_of macro will be used to retrieve its pointer.

Fixes: 1fde573413b5 ("s390: vfio-ap: base implementation of VFIO AP device driver")
Signed-off-by: Tony Krowiak 
Reviewed-by: Harald Freudenberger 
Link: https://lore.kernel.org/r/20230320150447.34557-1-akrowiak@linux.ibm.com
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

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

2023-03-03T22:41:50+00:00

Pull more SCSI updates from James Bottomley:
 "Updates that missed the first pull, mostly because of needing more
  soak time.

  Driver updates (zfcp, ufs, mpi3mr, plus two ipr bug fixes), an
  enclosure services (ses) update (mostly bug fixes) and other minor bug
  fixes and changes"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (32 commits)
  scsi: zfcp: Trace when request remove fails after qdio send fails
  scsi: zfcp: Change the type of all fsf request id fields and variables to u64
  scsi: zfcp: Make the type for accessing request hashtable buckets size_t
  scsi: ufs: core: Simplify ufshcd_execute_start_stop()
  scsi: ufs: core: Rely on the block layer for setting RQF_PM
  scsi: core: Extend struct scsi_exec_args
  scsi: lpfc: Fix double word in comments
  scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
  scsi: core: Fix a source code comment
  scsi: cxgbi: Remove unneeded version.h include
  scsi: qedi: Remove unneeded version.h include
  scsi: mpi3mr: Remove unneeded version.h include
  scsi: mpi3mr: Fix missing mrioc->evtack_cmds initialization
  scsi: mpi3mr: Use number of bits to manage bitmap sizes
  scsi: mpi3mr: Remove unnecessary memcpy() to alltgt_info->dmi
  scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()
  scsi: mpi3mr: Fix an issue found by KASAN
  scsi: mpi3mr: Replace 1-element array with flex-array
  scsi: ipr: Work around fortify-string warning
  scsi: ipr: Make ipr_probe_ioa_part2() return void
  ...