** 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 Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1786057 Title: qeth: don't clobber buffer on async TX completion Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Bug description: == 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. 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. Reproduction: Heavy multi-connection workload on an af_iucv 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1786057/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp