diff options
author | 2018-04-19 12:52:07 +0200 | |
---|---|---|
committer | 2018-04-22 14:42:31 -0400 | |
commit | 901e3f49facbd31b2b3d1786637b4a35e1022e9b (patch) | |
tree | 58b003cebb779adf39593748b9b478d2318e1d4d /tools/perf/scripts/python/export-to-postgresql.py | |
parent | s390/qeth: fix error handling in adapter command callbacks (diff) | |
download | wireguard-linux-901e3f49facbd31b2b3d1786637b4a35e1022e9b.tar.xz wireguard-linux-901e3f49facbd31b2b3d1786637b4a35e1022e9b.zip |
s390/qeth: avoid control IO completion stalls
For control IO, qeth currently tracks the index of the buffer that it
expects to complete the next IO on each qeth_channel. If the channel
presents an IRQ while this buffer has not yet completed, no completion
processing for _any_ completed buffer takes place.
So if the 'next buffer' is skipped for any sort of reason* (eg. when it
is released due to error conditions, before the IO is started), the
buffer obviously won't switch to PROCESSED until it is eventually
allocated for a _different_ IO and completes.
Until this happens, all completion processing on that channel stalls
and pending requests possibly time out.
As a fix, remove the whole 'next buffer' logic and simply process any
IO buffer right when it completes. A channel will never have more than
one IO pending, so there's no risk of processing out-of-sequence.
*Note: currently just one location in the code really handles this problem,
by advancing the 'next' index manually.
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions