[Bug 204426] Processes terminating cannot access memory

[email protected]
Newsgroups gmane.os.freebsd.devel.threading
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426

--- Comment #120 from [email protected] ---
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.