[lkml]   [2004]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: FW: Linux kernel file offset pointer races
On Wed, Aug 11, 2004 at 06:14:30PM -0300, Marcelo Tosatti wrote:
> On Wed, Aug 11, 2004 at 06:26:02PM +0400, Andrey Savochkin wrote:
> > BTW, f_pos assignments are non-atomic on IA-32 since it's a 64-bit value.
> > The file position is protected by the BKL in llseek(), but I do not see any
> > serialization neither in sys_read() nor in generic_file_read() and other
> > methods.
> >
> > Have we accepted that the file position may be corrupted after crossing 2^32
> > boundary by 2 processes reading in parallel from the same file?
> > Or am I missing something?
> Yes, as far as I know, parallel users of the same file descriptions (which
> can race on 64-bit architectures) is expected, we dont care about handling it.
> Behaviour is undefined.

I prefer explainable behaviours :)

If 2 processes start reading at offset 0xfffffffe, and one of them reads 1
byte and the second 2 bytes, I can expect the file position be 0xffffffff,
0x100000000, 0x100000001, or, in the worst case, 0xfffffffe again.
But 0x1ffffffff will be a real surprise.

For a bigger surprise, we can kill one of the processes with SIGFPE if we
find that the processes perform such an "incorrect" parallel read and the
file position has changed behind us ;)
But we don't want that much undefined behaviour, do we? :)

Best regards
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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