summaryrefslogtreecommitdiffstats
path: root/drivers/s390/crypto
diff options
context:
space:
mode:
authorHarald Freudenberger <freude@linux.ibm.com>2019-04-03 13:18:22 +0200
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2019-04-10 17:46:24 +0200
commit16222cfb96b02a4a3e38e52012f2a6304850c3c9 (patch)
tree749688b1dfb6adb9012e241ae4893153957e0b1e /drivers/s390/crypto
parent5712f3301a12c0c3de9cc423484496b0464f2faf (diff)
downloadlinux-16222cfb96b02a4a3e38e52012f2a6304850c3c9.tar.bz2
s390/zcrypt: fix possible deadlock situation on ap queue remove
With commit 01396a374c3d ("s390/zcrypt: revisit ap device remove procedure") the ap queue remove is now a two stage process. However, a del_timer_sync() call may trigger the timer function which may try to lock the very same spinlock as is held by the function just initiating the del_timer_sync() call. This could end up in a deadlock situation. Very unlikely but possible as you need to remove an ap queue at the exact sime time when a timeout of a request occurs. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reported-by: Pierre Morel <pmorel@linux.ibm.com> Fixes: commit 01396a374c3d ("s390/zcrypt: revisit ap device remove procedure") Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'drivers/s390/crypto')
-rw-r--r--drivers/s390/crypto/ap_queue.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/s390/crypto/ap_queue.c b/drivers/s390/crypto/ap_queue.c
index 6a340f2c3556..5ea83dc4f1d7 100644
--- a/drivers/s390/crypto/ap_queue.c
+++ b/drivers/s390/crypto/ap_queue.c
@@ -751,8 +751,8 @@ void ap_queue_prepare_remove(struct ap_queue *aq)
__ap_flush_queue(aq);
/* set REMOVE state to prevent new messages are queued in */
aq->state = AP_STATE_REMOVE;
- del_timer_sync(&aq->timeout);
spin_unlock_bh(&aq->lock);
+ del_timer_sync(&aq->timeout);
}
void ap_queue_remove(struct ap_queue *aq)