Demand paged executables

[ray]

In article <2765 at rti.UUCP> trt at rti.UUCP (Thomas Truscott) writes:
>In article <1997 at solo12.cs.vu.nl>, maart at cs.vu.nl (Maarten Litmaath) writes:
>> dg at lakart.UUCP (David Goodenough) writes:
>> > why is it not possible to unlink a demand paged program that is executing.
>> 
>> Huh? On 4.3BSD: ... it works fine
>In most System V systems you cannot unlink the last
>on-disk link to an executing program.
That is, only if you link the program so that it has a shared text segment.
This is the default on the Sys Vs I work on, but in all of them you can
force the linker to put text and data in the same region(segment.) When
linked in this fashion not only can you unlink the a.out you can overwrite
it.
>There is no particular reason for this, just remove the check
>(easiest if you have kernel source!) and everything works fine.
Problem I see for a.outs that have shared text.  
This is all from reading the Bach book, I have no access to source.  
>From the Bach book page 223,
"...the kernel searches the active region list for the file's text region,
identifying it as the one whose inode pointer matches the inode of the
executable file."
Consider what might happen if an a.out with shared text is started (process A).
Next the actual file is allowed to be removed.
Later an executable is created and happens to land at the same inode that the
previous a.out used.
Now, with process A still running (and thus its text region is still in the 
active list,) some one trys to run the new a.out. 
Seems to me, from reading Bach, the new process gets the old text segment and
the new data segment.  This SHOULD be LOADS of fun (particularly when data
or bss in the new a.out is smaller than in the original (at least a core dump
:-)).) 

A.outs with non-shared text, would not experience this problem since no 
search is made of the in memory active region list.

Just my 2 cents worth.
=
ray mit-eddie!uccba!spca6!ray