Re: file offset corruption on 32-bit machines?

[Bodo Eggert]

Diego Calleja <diegocg@xxxxxxxxx> wrote:

> El Thu, 10 Apr 2008 16:31:09 +0200 (CEST), Jiri Kosina <jkosina@xxxxxxx>
> escribió:
> 
>> I think this is worth fixing.
> 
> This question comes very often, and Linus even wrote a patch
> (http://lkml.org/lkml/2006/4/13/124 , http://lkml.org/lkml/2006/4/13/130)
> 
> But apparently there's no much interest in fixing it, because it would
> slow down some workloads...

AS far as I understand, the race is e.g.:

fpos := A:a, we want to make process/thread a read A:b or B:a without it
being a correct value in fpos. a!=b!=c, A!=B, A!=C.

a: read fpos.high (A:?)
b: write fpos (B:b)
a: read fpos.low (A:b)


If you change this to 

a: read fpos.high
a: read fpos.low
a: read fpos.high
a: read fpos.low

and compare the results, you need to

a: read fpos.high (A:?)
b: write fpos (B:b)
a: read fpos.low (A:b)
b: write fpos (A:c)
a: read fpos.high (A:b),(A:?)
b: write fpos (C:b)
a: read fpos.low (A:b),(A:b)

That would be winning three races in order to hit the bug. 


OTOH, writers MUST NOT be interrupted, because:

b: write fpos.high (B:a)
a: read fpos.high (B:?)
a: read fpos.low (B:a)
a: read fpos.high (B:a),(B:?)
a: read fpos.low (B:a),(B:a)
b: write fpos.low (B:b)


--
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/