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:2.258 / U:0.644 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site