Re: FW: Linux kernel file offset pointer races

Andrey Savochkin
2004-08-12T07:55:34Z

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
Andrey