Be more careful about marking buffers dirty
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 4 Apr 2008 21:38:17 +0000 (14:38 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 4 Apr 2008 21:38:17 +0000 (14:38 -0700)
commit1be62dc190ebaca331038962c873e7967de6cc4b
treea8eb0a106bf362819d2bb0fc602b0e52df6a4198
parent4ed919014eb2b591eb8fdd4dd00226a65faddef4
Be more careful about marking buffers dirty

Mikulas Patocka noted that the optimization where we check if a buffer
was already dirty (and we avoid re-dirtying it) was not really SMP-safe.

Since the read of the old status was not synchronized with anything, an
aggressive CPU re-ordering of memory accesses might have moved that read
up to before the data was even written to the buffer, and another CPU
that cleaned it again, causing the newly dirty state to never actually
hit the disk.

Admittedly this would probably never trigger in practice, but it's still
wrong.

Mikulas sent a patch that fixed the problem, but I dislike the subtlety
of the whole optimization, so this is an alternate fix that is more
explicit about the particular SMP ordering for the optimization, and
separates out the speculative reads of the buffer state into its own
conditional (and makes the memory barrier only happen if we are likely
to actually hit the optimized case in the first place).

I considered removing the optimization entirely, but Andrew argued for
it's continued existence. I'm a push-over.

Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/buffer.c