lkml.org 
[lkml]   [2008]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: file offset corruption on 32-bit machines?
    > Hello!
    >
    > > [*] file_pos_{read,write} (fs/read_write.c) are not called under lock (in
    > > sys_read, sys_write, ...), so even if f_pos is written atomically, you will
    > > be able to get races when accessing shared descriptor from different threads.
    >
    > There are however cases when such behavior is perfectly valid: For example
    > you can have a file of records of a fixed size, whose order does not matter.
    > Then multiple processes can produce the records in parallel, sharing
    > a single fd.
    Well, but noone guarantees that both processes don't read the same
    data.

    > > I think that POSIX states, that behavior is undefined under these conditions.
    >
    > Do you have a pointer to that?
    SUSv3 says:
    On files that support seeking (for example, a regular file), the read()
    shall start at a position in the file given by the file offset
    associated with fildes. The file offset shall be incremented by the
    number of bytes actually read.

    But nowhere is specified when this happens so OS is perfectly free to
    advance f_pos after read finishes when read from the other process is
    already running. And Linux does exactly that - actually, we do:
    pos = f_pos
    do reading which advances pos
    f_pos = pos

    So it can even in theory happen that one thread reads entries 1,2,3,2
    because the other thread in the mean time finished reading entry 1...

    Honza
    --
    Jan Kara <jack@suse.cz>
    SuSE CR Labs


    \
     
     \ /
      Last update: 2008-04-10 17:15    [W:0.021 / U:91.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site