[PATCH v4 0/1] Use mutex_lock_killable() in ap_bus_force_rescan()

[PATCH v4 0/1] Use mutex_lock_killable() in ap_bus_force_rescan()

[Harald Freudenberger]

A deep dive into the AP bus code and zcrypt device driver about the
usage of mutex locking showed that there is one questionable call in
ap_bus.c in function ap_bus_force_rescan(). This function may be
called in kernel and process context. In both contexts only one info
is important: was there a AP bus scan running and did it result in
some updates on the AP devices. So only true/false is returned but no
info like -EINTR. But still the mutex lock call should be
interruptible to be able to kill a user space program blocked forever
on this. So this patch replaces mutex_lock_interruptible() with
mutex_lock_killable() to  be able to handle SIGKILL especially in user
space process context.

v1 - initial version
v2 - with v1 came up some discussion from Holger and Heiko. Heiko especially
     wanted me to rephrase the header of the patch.
     However v2 went out with a rewrite of the code as discussed and suggested
     by Holger but Heikos complain were not addressed.
v3 - now and finally I rephrased the patch header. Let's see what feedback
     I'll get for this now.
v4 - Rephrased the subject, Reviewed-by updated

Harald Freudenberger (1):
  s390/ap: Use mutex_lock_killable() in ap_bus_force_rescan()

 drivers/s390/crypto/ap_bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH v4 1/1] s390/ap: Use mutex_lock_killable() in ap_bus_force_rescan()

[Harald Freudenberger]

A deep dive into the AP bus code and zcrypt device driver about the
usage of mutex locking showed that there is one questionable call in
ap_bus.c in function ap_bus_force_rescan(). This function may be
called in kernel and process context. In both contexts only one info
is important: was there a AP bus scan running and did it result in
some updates on the AP devices. So only true/false is returned but no
info like -EINTR. But still the mutex lock call should be
interruptible to be able to kill a user space program blocked forever
on this. So this patch replaces mutex_lock_interruptible() with
mutex_lock_killable() to  be able to handle SIGKILL especially in user
space process context.

Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
---
 drivers/s390/crypto/ap_bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 2d4e00a1e48c..d82df5b4e2db 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -1173,8 +1173,8 @@ bool ap_bus_force_rescan(void)
 	 * for the lock which means the other task has finished and
 	 * stored the result in ap_scan_bus_result.
 	 */
-	if (mutex_lock_interruptible(&ap_scan_bus_mutex)) {
-		/* some error occurred, ignore and go out */
+	if (mutex_lock_killable(&ap_scan_bus_mutex)) {
+		/* fatal signal received, go out */
 		goto out;
 	}
 	rc = ap_scan_bus_result;
-- 
2.43.0