Skip to contentSkip to conversation

Do not access buffers after dropping reference count

PATCH In review Lachlan McIlroy 2 participants 3 messages Jul 22, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Do not access buffers after dropping reference count

We should not access a buffer after dropping it's reference count otherwise we could race with another thread that releases the final reference count and frees the buffer causing us to access potentially unmapped memory.

Lachlan

xfs/linux-2.6/xfs_buf.c renamed from xfs/linux-2.6/xfs_buf.c_1.257 +0 -0
@@ -839,6 +839,7 @@ xfs_buf_rele(
		return;
	}
+	ASSERT(atomic_read(&bp->b_hold) > 0);
	if (atomic_dec_and_lock(&bp->b_hold, &hash->bh_lock)) {
		if (bp->b_relse) {
			atomic_inc(&bp->b_hold);
@@ -852,11 +853,6 @@ xfs_buf_rele(
			spin_unlock(&hash->bh_lock);
			xfs_buf_free(bp);
		}

- } else {
- /*
- * Catch reference count leaks
- */

-		ASSERT(atomic_read(&bp->b_hold) >= 0);
	}
}
#1 lore raw
Quoted 3 lines · Lachlan McIlroy

We should not access a buffer after dropping it's reference count otherwise we could race with another thread that releases the final reference count and frees the buffer causing us to access potentially unmapped memory.

Looks OK. The commit message should point out this is a problem only for DEBUG kernels, though.

Cheers,

Dave.

Signature · 2 lines
Dave Chinner
[email protected]
#2 lore raw
Quoted 7 lines · Dave Chinner
Quoted 3 lines · Lachlan McIlroy

We should not access a buffer after dropping it's reference count otherwise we could race with another thread that releases the final reference count and frees the buffer causing us to access potentially unmapped memory.

Looks OK. The commit message should point out this is a problem only for DEBUG kernels, though.

Okay, will do.