group.of.nepali.translators team mailing list archive

[Tim Gardner <tim.gardner@xxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu Xenial)
       Status: Fix Released => In Progress

** Changed in: linux (Ubuntu Wily)
     Assignee: Tim Gardner (timg-tpi) => (unassigned)

** Changed in: linux (Ubuntu Xenial)
     Assignee: (unassigned) => Tim Gardner (timg-tpi)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1584827

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

Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Wily:
  Invalid
Status in linux source package in Xenial:
  In Progress
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