kernel-packages team mailing list archive

[bugproxy <bugproxy@xxxxxxxxxx>]

------- Comment From geraldsc@xxxxxxxxxx 2016-06-14 12:30 EDT-------
I verified that the kernel in -proposed (4.4.0-25.44) fixes the problem.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-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/1584827

Title:
  s390/mm: fix asce_bits handling with dynamic pagetable levels

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Wily:
  Invalid
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released

Bug description:
  == Comment: #0 - Hendrik Brueckner <brueckner@xxxxxxxxxx> - 2016-05-23 09:17:08 ==
  Please backport the following linux stable commit ID:

  linux-stable: https://git.kernel.org/cgit/linux/kernel/git/stable
  /linux-
  stable.git/commit/?h=linux-4.4.y&id=ce1bc448bac01edfccdc26d8318cfd39aa09e6e0

  
  s390/mm: fix asce_bits handling with dynamic pagetable levels
  commit 723cacbd9dc79582e562c123a0bacf8bfc69e72a upstream.

  There is a race with multi-threaded applications between context switch and
  pagetable upgrade. In switch_mm() a new user_asce is built from mm->pgd and
  mm->context.asce_bits, w/o holding any locks. A concurrent mmap with a
  pagetable upgrade on another thread in crst_table_upgrade() could already
  have set new asce_bits, but not yet the new mm->pgd. This would result in a
  corrupt user_asce in switch_mm(), and eventually in a kernel panic from a
  translation exception.

  Fix this by storing the complete asce instead of just the asce_bits, which
  can then be read atomically from switch_mm(), so that it either sees the
  old value or the new value, but no mixture. Both cases are OK. Having the
  old value would result in a page fault on access to the higher level memory,
  but the fault handler would see the new mm->pgd, if it was a valid access
  after the mmap on the other thread has completed. So as worst-case scenario
  we would have a page fault loop for the racing thread until the next time
  slice.

  Also remove dead code and simplify the upgrade/downgrade path, there are no
  upgrades from 2 levels, and only downgrades from 3 levels for compat tasks.
  There are also no concurrent upgrades, because the mmap_sem is held with
  down_write() in do_mmap, so the flush and table checks during upgrade can
  be removed.

  Reported-by: Michael Munday <munday@xxxxxxxxxx>
  Reviewed-by: Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
  Signed-off-by: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
  Signed-off-by: Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
  Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1584827/+subscriptions