https://bugs.kde.org/show_bug.cgi?id=384732
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #7 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Mark Wielaard from comment #6)
> (In reply to Tom Hughes from comment #5)
> > We already detect CLONE_VFORK|CLONE_VM as a special case and deliberately
> > drop CLONE_VM because I imagine anything else would be a disaster as
> > valgrind's shadow memory etc would be shared.
>
> Sharing shadow memory should be fine since we do share the actual memory.
> But sharing the thread state is probably a problem.
>
> And indeed just not dropping VM_CLONE when we see VM_VFORK doesn't work.
> It does successfully create the child and execs the new process, but
> returning to the parent seg faults fairly soon.
Yes, that looks expected. For example, if the scheduler in the child process
has to regain control e.g. to translate a block in what follows the clone
syscall, then the parent host stack will be thrashed by the code executed by
the host child.
In other words, i highly suspect that the constraints of vfork syscall
apply for VM_CLONE+VM_VFORK (i.e. no function call, no return, ...).
What is tricky is that such constraints have to be respected both for
the guest and the host parts of the child;
>
> > The comments in the source explicitly mention preserving CLONE_VFORK to
> > preserve the wait-for-exec semantics and that does indeed seem to work.
>
> Earlier we did drop both CLONE_VFORK and CLONE_VM.
> And I can definitely see why CLONE_VM is bad without CLONE_VFORK.
>
> I am probable missing some bad sharing which messes things up.
> But I still wonder if we could handle CLONE_VFORK | CLONE_VM specially as if
> it was a simple thread creation (do_clone vs do_fork_clone) up till the
> actual exec/exit call (at which point we might have to do some magic to do
> the actual fork). Maybe too much bad voodoo though...
To fully respect the vfork semantic, all the threads have to be suspended
while the new thread has not yet done the exec, and nothing can happen
in these threds (e.g. signal handling or whatever).
It does look like a nice challenge to achieve.
--
You are receiving this mail because:
You are watching all bug changes.
