Re: CLONE_FILES problem.

Matthias Urlichs (smurf@smurf.noris.de)
Mon, 19 Aug 1996 12:30:03 +0100

In linux.dev.kernel, article <m0usIHF-0001qEC@atheist.tamu.edu>,
richard@atheist.tamu.edu (Richard Henderson) writes:
>
> A separate issue is that the kernel should be prepared to handle
> such situations in such a way that it does not crash but gracefully
> returns an error from the system call. (I don't know that such
> checks aren't there -- I havn't looked.)
>
Not really, unfortunately. What happens is that the close() call (or a
munmap() call, or...) pulls the rug from under the process who's currently
using the file descriptor or memory. This is no problem in user space,
obviously, but when the second process is in the middle of a kernel call
it's potentially disastrous.

The easiest solution is probably to add a global flag (and a wait list) to
the fd and mm structures -- close() and munmap() would be considered
"writers", and all other system calls would be "readers" as far as these
structures are concerned. Something should probably be done with
blocking accesses to files, i.e. if one thread is read()ing from a file
descriptor which another wants to close, the first should get a signal or
something.

-- 
You have had a long-term stimulation relative to business. Don't
become overly excited.

-- 
Matthias Urlichs         \  noris network GmbH  /  Xlink-POP Nürnberg 
Schleiermacherstraße 12   \   Linux+Internet   /   EMail: urlichs@noris.de
90491 Nürnberg (Germany)   \    Consulting+Programming+Networking+etc'ing
   PGP: 1024/4F578875   1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE
       Click <A HREF="http://info.noris.de/~smurf/finger">here</A>.    42