Re: Reset breakpoints on fork

[Roland McGrath <roland at redhat dot com>]

> Roland, I CCed you in the hope that you could maybe point out some nice
> way now or in the future to do this. 

There is no great magic to offer here, but I will be sure to keep this
wrinkle of the problem in mind for the future.

> This of course isn't very efficient since I assume the kernel could help
> us out here since it know the pages we touched through ptrace poke to
> set the breakpoints in the first place. 

In fact, it doesn't really.  There is no trail of this per se any more than
there is a trail of what memory writes the process itself made.  The
breakpoints normally go in read-only text pages, which did get COW'd when
you wrote them via ptrace.  It's probably possible to grovel around in the
VM data structures and figure out which read-only pages are COW copies.
But nothing distinguishes your pokes from the process itself doing
mprotect, then write to cause COW of a file-backed page, then mprotect back
to read-only.  For example, RELRO areas will always look that same way.

> If there was some way to have an event from the kernel where we got the
> forking and forked tasks in a quiescent state (at the same time) and then
> could inspect both and tell the kernel whether or not to copy the
> modified or original code pages that would be much better. 

Sorry, quiescent does not include "half-created".  When the child
exists, its address space has been populated.  fork is an atomic
operation.  Consider thread A in the parent running along while thread B
forks a child; then A calls munmap, etc.  The fork happens either before
or after anything A did.

> Bonus points for having advanced knowledge of a pending exec event, which
> would wipe away any changes we do anyway (although I don't see how this
> would be possible).

It's a mere matter of interpreting the machine code from the PC on,
solving the halting problem, etc.  ;-)

For advanced knowledge that an exec is likely, there is knowing that
it was a vfork.  Then an exec or an exit is inevitably entailed before
the parent runs again.  That's it.

Back at the dawn of time, one big idea was that fancy new VM tricks
would be the bee's knees for breakpoints.  VM tricks have great sex
appeal, but will be much deep voodoo to implement, and probably at least
slightly mind-bending to use (maybe true of sex appeal in general ;->).
The original thinking was to rely on this for breakpoints vs threads,
but that was before we clued in to the instruction-copying technique.
It might still be in the cards one day and a big win for e.g. per-thread
breakpoints, but it remains to be seen and is certainly a long way off
(after most of the rest of anything else anticipated for new kernel
features).  Much of that sex appeal is how clean and nice it can be for
issues like the one you are concerned with here.  But we'll be admiring
it from afar for a long time to come.


Thanks,
Roland