cvs commit: src/sys/vm vm_object.c vm_map.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

dillon      2004/07/28 13:40:35 PDT

DragonFly src repository

  Modified files:
    sys/vm               vm_object.c vm_map.c 
  Log:
  (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@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


http://www.dragonflybsd.org/cvsweb/src/sys/vm/vm_object.c.diff?r1=1.16&r2=1.17&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vm/vm_map.c.diff?r1=1.30&r2=1.31&f=u