------- Comment From h.carst...@de.ibm.com 2018-04-14 06:40 EDT-------
(In reply to comment #14)
> I built a 16.04(4.4 based kenrel) with the requested patch.
> The test kernel can be downloaded from:
> http://kernel.ubuntu.com/~jsalisbury/lp1761674/xenial
> Can you test this kernel and see if it resolves this bug?
> Note, to test this kernel, you need to install both the linux-image and
> linux-image-extra .deb packages.

The bug is close to impossible to reproduce, since it's a hard to hit
race. So I could only verify that the kernel/system still boots and did
some basic tests - which all passed.

------- Comment From h.carst...@de.ibm.com 2018-04-14 06:43 EDT-------
(In reply to comment #14)
> I also tried to apply this patch to the 4.13 based 17.10 Artful kernel.
> However, I'll have to perform allot of back porting for Artful.  For
> example, the patch relies on _raw_compare_and_swap().  However, this
> function was removed in v4.12-rc1 by commit 02c503f.  Can you confirm this
> patch is needed in Artful, and if you recommend any prereq patches?

Yes, the bug is also present in v4.13. I attached a kernel patch agains
vanilla v4.13 that is supposed to fix the bug for this kernel version as

** Tags removed: bugnameltc-166421 kernel-da-key severity-high

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  [Ubuntu 16.04] kernel: fix rwlock implementation

Status in Ubuntu on IBM z Systems:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Artful:
Status in linux source package in Bionic:
  Fix Released

Bug description:
  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 
                wait until CPU 1 removes the writer bit, which will never 
                since it waits for the first reader on CPU 0 to release the 
  Solution:     Revert the rwlock writer fairness semantics again.

To manage notifications about this bug go to:

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