[Bug 198163] Kernel panic in vm_reserv_populate()
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Thu Mar 19 01:41:37 UTC 2015
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198163
--- Comment #8 from commit-hook at freebsd.org ---
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
Log:
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
harmless.
PR: 198163
Reviewed by: kib
Tested by: pho
X-MFC after: r267213
Sponsored by: EMC / Isilon Storage Division
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-bugs
mailing list