@IBM: Since this is a Stable Release Update Update (SRU) situation the SRU process as described here applies - especially the section about verification: https://wiki.ubuntu.com/StableReleaseUpdates#Verification
For more details on the verification itself there is a separate Performing SRU Verificaton page: https://wiki.ubuntu.com/QATeam/PerformingSRUVerification key points in a case like this are (in my opinion): - Verification must be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates. Generally this will be with a system that is up to date from *-release, *-security, and *-updates, but not with other packages from *-proposed (except other packages built from the affected source package - they must be updated if generally installed) or *-backports. * Verification feedback from bug reporters and subscribers is greatly appreciated, too, especially if the update is hardware specific. In this case we consider an update as verified if it has at least two positive, no negative testimonials in the bug report, and the verification team just checks whether the new version still works for the main use cases (to check for major regressions). - Ensure all critical and high importance bugs are verified in a timely manner. (See comment #10 usually 5 working days.) Hence it's not only about the verification of a certain patch itself, but also about making sure to not introduce any regressions. But I recommend a full reading of the above links. -- 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/1761674 Title: [Ubuntu 16.04] kernel: fix rwlock implementation Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: Fix Committed Status in linux source package in Artful: Fix Committed Status in linux source package in Bionic: Fix Released Bug description: == SRU Justification == IBM reported this bug due to a regression introduced by mainline commit 94232a4332de. IBM has requested this SAUCE backport to resolve this regression in Artful and Xenial. With Bionic and v4.15, the rwlock code has been rewritten. See upstream gitcommit: eb3b7b848fb3 ("s390/rwlock: introduce rwlock wait queueing"). Since the upstream code has been rewritten there also won't be an upstream git commit id available which contains the attached fix. == Fix == UBUNTU: SAUCE: (no-up) s390: fix rwlock implementation == Regression Potential == Low. The backport was written and tested by IBM. It is specific 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: kernel: fix rwlock implementation Symptom: Kernel hangs, due to deadlock on an rwlock. Problem: With upstream commit 94232a4332de ("s390/rwlock: improve writer fairness") rwlock writer fairness was supposed to be implemented. If a writer tries to take an rwlock it sets unconditionally the writer bit within the lock word and waits until all readers have released the lock. This however can lead to a deadlock since rwlocks can be taken recursively by readers. If e.g. CPU 0 holds the lock as a reader, and CPU 1 wants to write-lock the lock, then CPU 1 sets the writer bit and afterwards busy waits for CPU 0 to release the lock. If now CPU 0 tries to read-lock the lock again (recursively) it will also busy wait until CPU 1 removes the writer bit, which will never happen, since it waits for the first reader on CPU 0 to release the lock. Solution: Revert the rwlock writer fairness semantics again. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1761674/+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
