Hi! On Sat, 22 Jun 2013 01:15:08 +0200, Richard Braun <rbr...@sceen.net> wrote: > On Sat, Jun 22, 2013 at 12:52:03AM +0200, Thomas Schwinge wrote: > > But anyway, what is the split-stack run-time/startup code doing so that > > it makes vm_allocate behave erratically? Isn't vm_allocate a real system > > call after all, but relies on some threadvar state? It's now too late to > > figure it out today, and I have enough other things on my plate anyway. > > But surely Richard and/or Samuel will have some comments on this? ;-) > > Unless I'm mistaken, vm_allocate (along with vm_map and vm_deallocate) > is never used through a real system call but always as an RPC from the > Hurd. To make sure that's the case, see if rpctrace catches the call.
Heh, I was so sure it was a system call, so it didn't even occur to me to
simply check this... Simple enough:
[...]
task48(pid17605)->vm_map (0 0 0 1 (null) 0 1 1 7 1) = 0x4 ((os/kern)
invalid argument)
task48(pid17605)->vm_protect (0 0 0 0) = 0
task48(pid17605)->vm_deallocate (0 4096) = 0
task48(pid17605)->vm_allocate (0 4096 1) = 0 0
[...]
(By the way, the zero-size vm_map is the one we discussed at
<http://news.gmane.org/find-root.php?message_id=%3C87sj8522zx.fsf%40kepler.schwinge.homeip.net%3E>.)
So, the split-stack runtime unmaps the zero page -- and then is happily
re-using it for the following page-sized allocation. So, vm_acllocate
doesn't behave erratically after all.
Grüße,
Thomas
pgpKIeP7MEw2C.pgp
Description: PGP signature
