Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Jun 2015 15:46:11 +0900
From: "D. Jeff Dionne" <jeff@...inux.org>
To: Rich Felker <dalias@...c.org>
Cc: "D. Jeff Dionne" <jeff@...inux.org>,
 Yoshinori Sato <ysato@...rs.sourceforge.jp>,
 "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
 "shumpei.kawasaki@...wc.com" <shumpei.kawasaki@...wc.com>
Subject: Re: Moving forward with sh2/nommu


> On Jun 12, 2015, at 3:37 PM, Rich Felker <dalias@...c.org> wrote:
>> 
>> This is not a nommu uClinux thing, it is a restriction we inherited
>> from BSD vfork(). It makes things much simpler (read: tractable at
>> all), actually.
> 
> I'm not talking about returning from the function that called vfork.
> This is about returning from vfork itself, to the caller of vfork.

>>>  The first return
>>> (in the child) would properly restore these registers, but subsequent
>>> execution in the child (in the function that called vfork, e.g. when
>>> it sets up the stack for a call to execl) could clobber the locations
>>> where they were saved on the stack, and when the parent resumed
>>> execution, it vfork would restore the wrong values, and very bad
>>> things could happen in the caller

Oh, I see what you were saying, sorry about that.  You are correct, there
can be no C stack frame for vfork(), I agree.

Cheers,
J.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.