Messages in this thread |  | | Date | Mon, 19 Aug 1996 12:36:05 +0200 | Subject | Re: CLONE_FILES problem. | From | (Patrick Schaaf) |
| |
In linux.dev.kernel you write:
>Alexey Kuznetsov wrote: >> Suppose that 2 processes share one fd table after clone with CLONE_FILES. >> One of them goes to a syscall, related to a descriptor (read, write etc.) >> and sleeps there... >> At this time cloned process closes this descriptor, >> file->f_count==1, so that it will succeed!!! >> So that, when the first process will wake up, this >> file will be already invalid. It would be cathastrophic.
>Yes, this is what will happen. However, it is IMHO, also correct. >What is broken in this case is two proceses manipulating the same >file descriptor concurrently.
Agreed.
>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.)
I just looked into it a bit, and I think the kernel _is_ in error in this case. A file read on ext2 goes to mm/filemap.c:generic_file_read(), and that function modifies filp->f_pos and ->f_reada after sleeps; this might modify a closed filp (somewhere on a free hash, I think), or it might already be allocated to a completely different file, maybe for another user. Ugh.
Hmm, would it be a solution to increase f_count on all syscalls that might sleep, and decrease it when they return?
bye Patrick
|  |