Re: iohelp handle_io_release_conch doesn't lock shared page

[Roland McGrath]

> Only that it's essentially untested, and really deprecated.  Roland, do
> you think it's worth keeping around?  Is there another way to guarantee
> correct exec behavior?  (Like, say, reading the entire file in a single
> RPC; is that enough?)

I didn't realize that the io_map_cntl stuff was deprecated in your eyes.
(That doesn't mean we didn't have a conversation with that conclusion, I
may have just forgotten.)  It's certainly never been used.  But we've also
never actually had the execve vs write atomicity guarantee.  (Note that
AFAICT there is no specification anywhere that requires atomicity of execve
vs write.  POSIX.1-1996 talks only about read vs write, and extends this to
stdio and other things via the "underlying function" clauses--but there are
no such clauses applying to exec.  AFAIK other systems do not always
provide this guarantee, e.g. none I'm aware of do for NFS; I don't know
whether other current systems in fact make the guarantee for disk files.)
I'm not saying it's not a worthwhile thing to have, but just to put in
perspective how much hassle and other inefficiencies it might really be worth.

I am dubious about the idea of an io_read for the entire file in exec.
That approach presumes the filesystem will be doing something as lazy for
io_read as it does for mapping.  Maybe diskfs does, but it still seems
dicey in principle.  And I wonder how the overhead of the io_read to
vm_copy to ool reply of pages mapped to self compares to the overhead of
io_map to the other guy's vm_map.  Even if the io is delayed, I am still
uncomfortable with having to consume arbitrary chunks of address space in
exec during the procedure.  An executable file with debug symbols can be
very huge, and exec would have to do the single io_read to get it all
before looking in the first page to discover what tiny fraction needs to go
into the process image.  This might be a relatively quick window, but
there's no reason there shouldn't be 2000 of them going on simultaneously
and just the rare possibility of running out of address space in exec for
an instant introduces either unreliability or a bunch of hair in the code
to cope with waiting and retrying or capping the maximum number and so forth.