lkml.org 
[lkml]   [1999]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [patch] flushpage SMP race with ll_rw_block/bdflush
On Wed, 1 Sep 1999, David S. Miller wrote:

>On the otherhand, I cannot convince myself that your change is safe
>and %100 fixes the race and also does not create new ones.

My change seems safe to me because once you have the buffer clean
ll_rw_block will become harmless.

So you only need to check for a just started ll_rw_block and you'll be
done. If an ll_rw_block is not started yet then it will be harmless when
it will happens.

Both the lock bit and the dirty bit are always touched with atomic
operations except in wait_on_buffer() where it's a read.

Talking about the b_sate reads (__buffer_state()), IMO it would be safer
to change __buffer_state to use test_bit to avoid the compiler to cache
the b_state variable in registers (b_state is not volatile).

--- 2.3.16-bufferlock/include/linux/fs.h.~1~ Wed Sep 1 15:54:49 1999
+++ 2.3.16-bufferlock/include/linux/fs.h Wed Sep 1 18:00:14 1999
@@ -237,7 +237,7 @@
typedef void (bh_end_io_t)(struct buffer_head *bh, int uptodate);
void init_buffer(struct buffer_head *, bh_end_io_t *, void *);

-#define __buffer_state(bh, state) (((bh)->b_state & (1UL << BH_##state)) != 0)
+#define __buffer_state(bh, state) test_bit(BH_##state, &(bh)->b_state)

#define buffer_uptodate(bh) __buffer_state(bh,Uptodate)
#define buffer_dirty(bh) __buffer_state(bh,Dirty)

Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.056 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site