** 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

Reply via email to