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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
