>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