Re: file offset corruption on 32-bit machines?

[Jan Kara]

> 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@xxxxxxx>
SuSE CR Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/