APPLIED(Bionic): [SRU][Cosmic][Bionic][Xenial][PATCH 0/1] Fixes for LP1801686 [v2]

Khaled Elmously khalid.elmously at canonical.com
Thu Nov 8 04:22:49 UTC 2018


This patch already exists in Xenial as 75443f02ecfdd7c8e998063f9371f046126a21d5 which was part of the update to 4.4.154
This patch already exists in Cosmic as 0f4772f38723c41bf79c8ca1f58a00723e900749 which was part of the update to 4.18.6

Applied only to bionic/master-next



On 2018-11-06 16:22:50 , Frank Heimes wrote:
> BugLink: http://bugs.launchpad.net/bugs/1801686
> 
> == SRU Justification ==
> 
> Description: qdio: reset old sbal_state flags
> 
> Symptom:
>    af_iucv socket using HiperSockets may stall.
> Problem:
>    When allocating a new AOB fails, handle_outbound() is
> still capable of transmitting the selected buffer
> (just without async completion).
> But if a previous transfer on this queue slot used
> async completion, its sbal_state flags field is still set
> to QDIO_OUTBUF_STATE_FLAG_PENDING.
> So when the upper layer driver sees this stale flag, it
> expects an async completion that never happens.
> Solution:
>    Unconditionally clear the buffer's flags field.
> 
> == Fix ==
> 
> 64e03ff72623b8c2ea89ca3cb660094e019ed4ae ("s390/qdio: reset old sbal_state
> flags")
> 
> == Regression Potential ==
> 
> Low, because:
> - s390x only
> - further limited to qeth driver (OSA Express networking)
> - changes are limited to two files and 6 lines
>    - arch/s390/include/asm/qdio.h b/arch/s390/include/asm/qdio.h
>    - drivers/s390/cio/qdio_main.c b/drivers/s390/cio/qdio_main.c
> - error was identified at IBM/customer, fix was created there and tested
> upfront
> - (changes are upstream in 4.20 (according to bug description,
>    but in 4.19 according to 'git tag'),
>    hence will make it automatically into 'disco')
> 
> == Test Case ==
> 
> Test case / reproduction:
> Error inject and then simulate out-of-memory situation.

> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team




More information about the kernel-team mailing list