(From Alan):

(From Alan):
 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.

(From Matt):
 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
 different).

 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
 them already).

 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@cs.rice.edu>
See also: FreeBSD vm_object.c/1.329