Description of problem:

Bug 464520 describes a problem with the ptrace setoptions behavior on vfork.
That bug is fixed in latest 2.6.27 kernels, but it reveals a different problem.
The new behavior when ptraceing a vfork()ed child now retains the vfork()
shared page semantics (semantics which POSIX says no one should expect :-).

This is a non backward compatible change, the previous behavior of
ptraceing across a vfork resulted in the vfork being treated as a fork,
with the parent and child getting separate copies of memory pages.

In a multi-process debugger (such as the one I work on all the time), this
presents fantastic bookkeeping problems. Out of the blue, modifying
one process will (behind the debugger's back) modify a different process
at the same time.

I concede the desirability of being able to ptrace across a vfork without
changing the semantics of a non-ptraced vfork, but there are advantages the
other way as well, and since it has always worked the other way, I maintain
it should continue to work the other way (i.e. as through it were a fork,
not a vfork).

If you want to support the new semantics, it seem like the proper way to
do it would be by adding something like PTRACE_O_VFORKSHARESPAGES so
people needing the new semantics can explicitly request it rather than
having it unexpectedly thrust upon them.

Version-Release number of selected component (if applicable):
2.6.27-3.fc10

How reproducible:
every time

Steps to Reproduce:
1. I can produce a test program if anyone really needs one.
2.
3.
  
Actual results:
shared memory between parent and child across a ptrace

Expected results:
original behavior of vfork being treated as fork

Additional info: