From 368691543272cc524b9923db83106aafe791ffae Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Sat, 14 Aug 2010 21:37:56 +1000 Subject: [PATCH] Cleaner: add a memory barrier to ensure we see i_size promptly. There is a possible race that we need a barrier to protect against. I think... or hope. Signed-off-by: NeilBrown --- clean.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/clean.c b/clean.c index bb7a3c2..6cc09f5 100644 --- a/clean.c +++ b/clean.c @@ -340,8 +340,17 @@ static void cleaner_parse(struct fs *fs, struct toclean *tc) list_add_tail(&b->cleaning, &tc->cleaning); } - /* FIXME do I need a memory barrier. to ensure truncate - * sees the not-list_empty, and we see i_size? */ + /* We can race with truncate here, so need to check + * i_size again now that b->cleaning is non-empty. + * The thread doing the truncate will have to lock + * the page holding this block, which should be enough + * of a barrier so that if it sets i_size after now, + * it will see that b->cleaning is non-empty. + * We need to be sure that if it sets it before now, + * we get to see i_size. + * So I think a memory barrier is a good idea... + */ + mb(); if (LAFSI(ino)->type == 0 || (LAFSI(ino)->type >= TypeBase && -- 2.39.5