** Description changed:
+
+ == SRU Justification ==
+ IBM is requesting this commit for s390. This fixes a bug introduced by
+ mainline commit 0da9581ddb0f. The symptom of the bug is Failing transmissions
+ on af_iucv HiperTransport socket.
+
+ Xenial also needs this patch, but it required a backport, so it will be
+ SRU'd separately.
+
+ == Fix ==
+ ce28867fd20c ("s390/qeth: don't clobber buffer on async TX completion")
+
+ == Regression Potential ==
+ Low. Limited to s390.
+
+ == Test Case ==
+ A test kernel was built with this patch and tested by the original bug
reporter.
+ The bug reporter states the test kernel resolved the bug.
+
+
+
+
Description: qeth: don't clobber buffer on async TX completion
Symptom: Failing transmissions on af_iucv HiperTransport socket.
Problem: If qeth_qdio_output_handler() detects that a transmit
- requires async completion, it replaces the pending buffer's
- metadata object (qeth_qdio_out_buffer) so that this queue
- buffer can be re-used while the data is pending completion.
- Later when the CQ indicates async completion of such a
- metadata object, qeth_qdio_cq_handler() tries to free any
- data associated with this object (since HW has now completed
- the transfer). By calling qeth_clear_output_buffer(), it
- erronously operates on the queue buffer that _previously_
- belonged to this transfer ... but which has been potentially
- re-used several times by now. This results in double-free's
- of the buffer's data, and failing transmits as the buffer
- descriptor is scrubbed in mid-air.
+ requires async completion, it replaces the pending buffer's
+ metadata object (qeth_qdio_out_buffer) so that this queue
+ buffer can be re-used while the data is pending completion.
+ Later when the CQ indicates async completion of such a
+ metadata object, qeth_qdio_cq_handler() tries to free any
+ data associated with this object (since HW has now completed
+ the transfer). By calling qeth_clear_output_buffer(), it
+ erronously operates on the queue buffer that _previously_
+ belonged to this transfer ... but which has been potentially
+ re-used several times by now. This results in double-free's
+ of the buffer's data, and failing transmits as the buffer
+ descriptor is scrubbed in mid-air.
Solution: First only scrub the queue buffer when it is prepared
- for re-use, and later obtain the data addresses from
- the async-completion notifier (ie. the AOB), instead
- of the queue buffer.
+ for re-use, and later obtain the data addresses from
+ the async-completion notifier (ie. the AOB), instead
+ of the queue buffer.
Reproduction: Heavy multi-connection workload on an af_iucv
- HiperTransport socket.
+ HiperTransport socket.
Upstream-ID: ce28867fd20c23cd769e78b4d619c4755bf71a1c
Kernel 4.18
Will be introduced with kernel 4.18 in Cosmic.
But should also be applied to Bionic and Xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1786057
Title:
qeth: don't clobber buffer on async TX completion
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1786057/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs