On Fri 11-04-08 09:55:44, Lennart Sorensen wrote: > On Fri, Apr 11, 2008 at 02:24:34PM +0200, Bodo Eggert wrote: > > 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) > > So if you write multithreaded code and don't understand what locking > around shared resources is for, then your application might break. Can > you give an example where locking is being used correctly where this can > possibly fail? The kernel can't prevent idiots from writing bad code > that breaks. > > I just don't get this "problem". Well, as Jiri Kosina wrote, this isn't a problem unless someone finds a way how to use this race for some attack (and for example making f_pos negative compromises security so it is not so far-fetched as it would seem). So proactively fixing this makes some sence. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
