s390/zcrypt: fix possible deadlock situation on ap queue remove
With commit01396a374c
("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: commit01396a374c
("s390/zcrypt: revisit ap device remove procedure") Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
This commit is contained in:
parent
5712f3301a
commit
16222cfb96
|
@ -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)
|
||||
|
|
Loading…
Reference in New Issue