s390/qeth: fix af_iucv notification race
authorJulian Wiedmann <jwi@linux.ibm.com>
Fri, 20 Nov 2020 09:09:38 +0000 (10:09 +0100)
committerJakub Kicinski <kuba@kernel.org>
Sat, 21 Nov 2020 02:59:48 +0000 (18:59 -0800)
commit8908f36d20d8ba610d3a7d110b3049b5853b9bb1
tree65a2d0be18a156d4de19b615cba565d0b67f4683
parent34c7f50f7d0d36fa663c74aee39e25e912505320
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>
drivers/s390/net/qeth_core.h
drivers/s390/net/qeth_core_main.c