Messages in this thread | | | Date | Wed, 2 Apr 2008 15:01:58 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH]: Fix SMP-reordering race in mark_buffer_dirty |
| |
On Wed, 2 Apr 2008 12:44:05 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Wed, 2 Apr 2008, Mikulas Patocka wrote: > > + /* > > + * Make sure that the test for buffer_dirty(bh) is not reordered with > > + * previous modifications to the buffer data. > > + * -- mikulas > > + */ > > + smp_mb(); > > WARN_ON_ONCE(!buffer_uptodate(bh)); > > if (!buffer_dirty(bh) && !test_set_buffer_dirty(bh)) > > At that point, the better patch is to just *remove* the buffer_dirty() > test, and rely on the stronger ordering requirements of > test_set_buffer_dirty(). > > The whole - and only - point of the buffer_dirty() check was to avoid the > more expensive test_set_buffer_dirty() call, but it's only more expensive > because of the barrier semantics. So if you add a barrier, the point goes > away and you should instead remove the optimization.
But then the test-and-set of an already-set flag would newly cause the cacheline to be dirtied, requiring additional bus usage to write it back?
The CPU's test-and-set-bit operation could of course optimise that away in this case. But does it?
| |