DragonFly commits List (threaded) for 2004-07
cvs commit: src/sys/vm vm_object.c vm_map.c
dillon 2004/07/28 13:40:35 PDT
DragonFly src repository
sys/vm vm_object.c vm_map.c
Correct a very old error in both vm_object_madvise() (originating in
vm/vm_object.c revision 1.88) and vm_object_sync() (originating in
vm/vm_map.c revision 1.36): When descending a chain of backing objects,
both use the wrong object's backing offset. Consequently, both may
operate on the wrong pages.
In DragonFly the code needing correction is in vm_object_madvise() and
vm_map_clean() (that code in vm_map_clean() was moved to vm_object_sync()
in FreebSD-5 hence the FreeBSD-5 correction made by Alan was slight
The madvise case could produce corrupted user memory when MADV_FREE was
used, primarily on server-forked processes (where shadow objects exist)
PLUS a special set of additional circumstances: (1) The deeper shadow
layers had to no longer be shared, (2) Either the memory had been swapped
out in deeper shadow layers (not just the first shadow layer), resulting
in the wrong swap space being freed, or (2) the forked memory had not yet
been COW'd (and the deeper shadow layer is no longer shared) AND also had
not yet been collapsed backed into the parent (e.g. the original parent
and/or other forks had exited and/or the memory had been isolated from
This bug could be responsible for all of the sporatic madvise oddness
that has been reported over the years, especially in earlier days when
systems had less memory and paged to swap a lot more then they do today.
These weird failure cases have led people to generally not use MADV_FREE
(in particular the 'H' malloc.conf option) as much as they could. Also
note that I tightened up the VM object collapse code considerably in
FreeBSD-4.x making the failure cases above even less likely to occur.
The vm_map_clean() (vm_object_sync() in FreeBSD-5) case is not likely
to produce failures and it might not even be possible for it to occur
in the first place since it requires PROT_WRITE mapped vnodes to exist
in a backing object, which either might not be possible or might only occur
under extrodinary circumstances. Plus the worst that happens is that the
vnode's data doesn't get written out immediately (but always will later on).
Kudos to Alan for finding this old bug!
Noticed and corrected by: Alan Cox <alc@xxxxxxxxxxx>
See also: FreeBSD vm_object.c/1.329
Revision Changes Path
1.17 +2 -2 src/sys/vm/vm_object.c
1.31 +1 -1 src/sys/vm/vm_map.c