Bug 467122 - [utrace] restore original semantics to PTRACE_O_TRACEVFORK
Summary: [utrace] restore original semantics to PTRACE_O_TRACEVFORK
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-15 20:25 UTC by Tom Horsley
Modified: 2008-10-17 19:18 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-10-17 19:18:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom Horsley 2008-10-15 20:25:42 UTC
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:

Comment 1 Roland McGrath 2008-10-17 00:52:22 UTC
The description is inaccurate AFAIK.  Please produce a test program that demonstrates on some past vanilla kernel where PTRACE_O_TRACEVFORK changed the meaning of vfork.

Comment 2 Tom Horsley 2008-10-17 14:00:44 UTC
Yikes! Sorry about the noise. I did write a test program, but it
always says memory is indeed shared on all the fedora and rhel kernels
I've tried. I've definitely seen the non-shared behavior, but I
guess that was only with some custom kernels, so turning vfork
into fork must be something we did either accidentally or deliberately.
I guess I need to poke around some more and clear up my confusion
about which kernels this happens on.

Comment 3 Roland McGrath 2008-10-17 19:18:10 UTC
The strace utility does tweak vfork syscalls to be fork syscalls.
Maybe that's what you were thinking of.


Note You need to log in before you can comment on or make changes to this bug.