[Bug 240061] MADV_FREE rewinds time to before fork()

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240061

            Bug ID: 240061
           Summary: MADV_FREE rewinds time to before fork()
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: nwf20 at cl.cam.ac.uk

MADV_FREE simply cleans pages associated with the current object backing the
advisee region so that the act of page reclaimation will remove it if needed.

If there is no shadowed object, this is fine: if the page is removed, it will
be demand-zeroed, and if it isn't removed, it will be as it was before
MADV_FREE.

In the case there is a shadowed object (i.e., these pages are CoW; say, they
were mapped before fork()), however, if the page is removed, it will not be
demand zeroed: it will be copied up from the shadowed object.  It is therefore
possible to selectively rewind time to before fork() and expose whatever
information was in these pages.  (I have a test program that demonstrates the
effect, but as it relies on inducing memory pressure, it is rude for a test
suite; it would be nice if there were a synthetic way to cause the page reclaim
subsystem to run even without true memory pressure.)

#1851 makes somewhat oblique reference to an issue with MADV_FREE and I presume
that it is this behavior that is being commented upon, but it's hard to say for
sure.  Perhaps this behavior was indeed eliminated in 1997, but it's back now.

In any case, I *believe*, not being very familiar with the VM subsystem, that
vm_map_madvise() needs to...

  consider MADV_FREE a modify_map=true operation and...

  for each map entry within the advisee region, call vm_object_split() and then
release the backing object...

  then call pmap_advise() and vm_object_madvise() on this new object.

There may well be a better way to do this; it may, in fact, be desirable to
treat MADV_FREE as if it were mmap()-ing a new entry and new object when the
advisee object is OBJT_DEFAULT or OBJT_SWAP; I am less sure what MADV_FREE's
semantics should be if it's OBJT_VNODE, for example.

-- 
You are receiving this mail because:
You are the assignee for the bug.