Bug 198163 - Kernel panic in vm_reserv_populate()
Summary: Kernel panic in vm_reserv_populate()
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2015-03-02 14:01 UTC by ikosarev
Modified: 2017-04-23 18:24 UTC (History)
4 users (show)

See Also:

The test source. (6.14 KB, text/plain)
2015-03-02 14:01 UTC, ikosarev
no flags Details
Core dumped (74.91 KB, text/plain)
2015-03-02 14:03 UTC, ikosarev
no flags Details
picture from stack-trace (876.02 KB, image/jpeg)
2015-03-03 18:26 UTC, Oliver Pinter
no flags Details
VirtualBox config used (7.71 KB, text/xml)
2015-03-04 11:40 UTC, ikosarev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description ikosarev 2015-03-02 14:01:18 UTC
Created attachment 153661 [details]
The test source.

See attached for the minimzed source.

How to reproduce:
$ clang fork.cc -o fork.cc.tmp
$ ./fork.cc.tmp
Comment 1 ikosarev 2015-03-02 14:03:33 UTC
Created attachment 153662 [details]
Core dumped
Comment 2 ikosarev 2015-03-02 17:57:59 UTC
Worth mentioning that this bug prevents the Clang's memory sanitizer (Msan) from working on FreeBSD 11.
Comment 3 Konstantin Belousov freebsd_committer 2015-03-03 16:20:40 UTC
I tried to reproduce this on sandy bridge machine on real hardware, and was not able to.  The program was run dozen times without causing the issue.

It is curious how limited are the CPU features reported compared to the CPU herald string.  In particular, the popcnt support is not claimed, which is used by amd64 pmap when available.
Comment 4 Oliver Pinter freebsd_committer 2015-03-03 18:26:19 UTC
Created attachment 153727 [details]
picture from stack-trace
Comment 5 Oliver Pinter freebsd_committer 2015-03-03 18:26:56 UTC
Try to run this program more than one time (~8-10 run). I'm able to
reproduce this error on a Haswell based system, but there are no core
dump, only a stacktrace.
Comment 6 ikosarev 2015-03-04 11:40:54 UTC
Created attachment 153772 [details]
VirtualBox config used
Comment 7 ikosarev 2015-03-04 11:47:10 UTC
I've attached the VirtualBox config used. I can reproduce the defect on a clean just-installed system, r277486 specifically.
Comment 8 commit-hook freebsd_committer 2015-03-19 01:41:37 UTC
A commit references this bug:

Author: alc
Date: Thu Mar 19 01:40:44 UTC 2015
New revision: 280238
URL: https://svnweb.freebsd.org/changeset/base/280238

  Fix the root cause of the "vm_reserv_populate: reserv <address> is already
  promoted" panics.  The sequence of events that leads to a panic is rather
  long and circuitous.  First, suppose that process P has a promoted
  superpage S within vm object O that it can write to.  Then, suppose that P
  forks, which leads to S being write protected.  Now, before P's child
  exits, suppose that P writes to another virtual page within O.  Since the
  pages within O are copy on write, a shadow object for O is created to
  house the new physical copy of the faulted on virtual page.  Then, before
  P can fault on S, P's child exists.  Now, when P faults on S, it will
  follow the "optimized" path for copy-on-write faults in vm_fault(),
  wherein the underlying physical page is moved from O to its shadow object
  rather than allocating a new page and copying the new page's contents from
  the old page.  Moreover, suppose that every 4 KB physical page making up S
  is moved to the shadow object in this way.  However, the optimized path
  does not move the underlying superpage reservation, which is the root
  cause of the panics!  Ultimately, P performs vm_object_collapse() on O's
  shadow object, which destroys O and in doing so breaks any reservations
  still belonging to O.  This leaves the reservation underlying S in an
  inconsistent state: It's simultaneously not in use and promoted.  Breaking
  a reservation does not demote it because I never intended for a promoted
  reservation to be broken.  It makes little sense.  Finally, this
  inconsistency leads to an assertion failure the next time that the
  reservation is used.

  The failing assertion does not (currently) exist in FreeBSD 10.x or
  earlier.  There, we will quietly break the promoted reservation.  While
  illogical and unintended, breaking the reservation is essentially

  PR:		198163
  Reviewed by:	kib
  Tested by:	pho
  X-MFC after:	r267213
  Sponsored by:	EMC / Isilon Storage Division

Comment 9 commit-hook freebsd_committer 2015-04-02 19:11:31 UTC
A commit references this bug:

Author: alc
Date: Thu Apr  2 19:10:34 UTC 2015
New revision: 281001
URL: https://svnweb.freebsd.org/changeset/base/281001

  MFC r280238
    Fix the root cause of the "vm_reserv_populate: reserv <address> is already
    promoted" panics.

  PR:		198163

_U  stable/10/