Messages in this thread |  | | From | Matthias Urlichs <> | Subject | Re: CLONE_FILES problem. | Date | 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
|  |