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

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