lkml.org 
[lkml]   [2006]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: PROBLEM: pthread-safety bug in write(2) on Linux 2.6.x
    From
    Date
    On Iau, 2006-04-13 at 08:01 -0700, Linus Torvalds wrote:
    > That said, I wouldn't be 100% against it, especially under certain
    > circumstances. However, the circumstances when I think it might be
    > acceptable are fairly specific:
    >
    > - when we use f_pos (ie we'd synchronize write against write, but only
    > per "struct file", not on an inode basis)
    > - only for files that are marked seekable with FMODE_LSEEK (thus avoiding
    > the stream-like objects like pipes and sockets)
    >
    > Under those two circumstances, I'd certainly be ok with it, and I think we
    > could argue that it is a "good thing". It would be a "f_pos" lock (so we
    > migt do it for reads too), not a "data lock".

    The only serious case historically has been O_APPEND which does have
    pretty precise semantics. Nowdays we also have pread/pwrite which have
    pretty clear semantics and deal with threading. The O_APPEND case is
    very important to get correct and 2.4 certainly did so.


    Looking at the spec it says the following

    "If the O_APPEND flag of the file status flags is set, the file offset
    shall be set to the end of the file prior to each write and no
    intervening file modification operation shall occur between changing the
    file offset and the write operation."

    This is what 2.4 took great paints to guarantee for file writes. Now in
    actual fact no OS I know of implements this to the extreme (mmap) but
    does for the other cases.

    Outside of O_APPEND the specification says only that
    - The write starts at the file position
    - The file position is updated before the syscall returns

    It makes no other guarantee I can see.


    As such I belive that the O_APPEND case must be kept locked properly and
    the non O_APPEND cases are already correctly handled by the kernel. That
    seems to argue for f_pos serialization on O_APPEND only.

    Alan








    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-13 23:43    [W:4.058 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site