[Bug 204426] Processes terminating cannot access memory

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Jun 27 21:54:40 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426

--- Comment #120 from commit-hook at freebsd.org ---
A commit references this bug:

Author: kib
Date: Mon Jun 27 21:54:20 UTC 2016
New revision: 302236
URL: https://svnweb.freebsd.org/changeset/base/302236

Log:
  If the vm_fault() handler raced with the vm_object_collapse()
  sleepable scan, iteration over the shadow chain looking for a page
  could find an OBJ_DEAD object.  Such state of the mapping is only
  transient, the dead object will be terminated and removed from the
  chain shortly.  We must not return KERN_PROTECTION_FAILURE unless the
  object type is changed to OBJT_DEAD in the chain, indicating that
  paging on this address is really impossible.  Returning
  KERN_PROTECTION_FAILURE prematurely causes spurious SIGSEGV delivered
  to processes, or kernel accesses to UVA spuriously failing with
  EFAULT.

  If the object with OBJ_DEAD flag is found, only return
  KERN_PROTECTION_FAILURE when object type is already OBJT_DEAD.
  Otherwise, sleep a tick and retry the fault handling.

  Ideally, we would wait until the OBJ_DEAD flag is resolved, e.g. by
  waiting until the paging on this object is finished.  But to do so, we
  need to reference the dead object, while vm_object_collapse() insists
  on owning the final reference on the collapsed object.  This could be
  fixed by e.g. changing the assert to shared reference release between
  vm_fault() and vm_object_collapse(), but it seems to be too much
  complications for rare boundary condition.

  PR:   204426
  Tested by:    pho
  Reviewed by:  alc
  Sponsored by: The FreeBSD Foundation
  X-Differential revision:      https://reviews.freebsd.org/D6085
  MFC after:    2 weeks
  Approved by:  re (gjb)

Changes:
  head/sys/vm/vm_fault.c

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-threads mailing list