]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit407bc26fe7e406623a689a9e10855df7514f8b4f
treea8eb0a106bf362819d2bb0fc602b0e52df6a4198
parentec9319ffb2af4e30fadc95993e7bb29c17d8c584
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