lkml.org 
[lkml]   [2008]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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?




\
 
 \ /
  Last update: 2008-04-03 00:07    [W:0.082 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site