lkml.org 
[lkml]   [1996]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CLONE_FILES problem.
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.063 / U:1.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site