summaryrefslogtreecommitdiffstats
path: root/drivers/block
diff options
context:
space:
mode:
authorJulian Wiedmann <jwi@linux.ibm.com>2020-11-20 10:09:38 +0100
committerJakub Kicinski <kuba@kernel.org>2020-11-20 18:59:48 -0800
commit8908f36d20d8ba610d3a7d110b3049b5853b9bb1 (patch)
tree65a2d0be18a156d4de19b615cba565d0b67f4683 /drivers/block
parent34c7f50f7d0d36fa663c74aee39e25e912505320 (diff)
downloadlinux-8908f36d20d8ba610d3a7d110b3049b5853b9bb1.tar.bz2
s390/qeth: fix af_iucv notification race
The two expected notification sequences are 1. TX_NOTIFY_PENDING with a subsequent TX_NOTIFY_DELAYED_*, when our TX completion code first observed the pending TX and the QAOB then completes at a later time; or 2. TX_NOTIFY_OK, when qeth_qdio_handle_aob() picked up the QAOB completion before our TX completion code even noticed that the TX was pending. But as qeth_iqd_tx_complete() and qeth_qdio_handle_aob() can run concurrently, we may end up with a race that results in a sequence of TX_NOTIFY_DELAYED_* followed by TX_NOTIFY_PENDING. Which would confuse the af_iucv code in its tracking of pending transmits. Rework the notification code, so that qeth_qdio_handle_aob() defers its notification if the TX completion code is still active. Fixes: b333293058aa ("qeth: add support for af_iucv HiperSockets transport") Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'drivers/block')
0 files changed, 0 insertions, 0 deletions