On Sat, 5 Aug 2000, Alexander Viro wrote:
[BUG() in ext2_new_block() being triggered]
> _If_ that assertion is triggered - too bad, it means that we just didn't
> notice that leak until now.
Ah... I see how it happens:
Process A:
ext2_alloc_block() has a preallocation miss.
ext2_alloc_block() call ext2_discard_prealloc().
ext2_alloc_block() calls ext2_new_block().
ext2_new_block() blocks on ->s_lock.
Process B:
ext2_alloc_block() notices that we have no preallocated blocks
ext2_alloc_block() calls ext2_new_block().
ext2_new_block() blocks on ->s_lock.
After a while current owner of ->s_lock unlocks it.
Either A or B wins the race - doesn't matter, suppose it was A.
In A:
ext2_new_block() does preallocation.
ext2_new_block() unlocks ->s_lock.
In B:
ext2_new_block() does preallocation... and assuming that
preallocated stuff had been freed by caller blindly sets
->i_prealloc_{block,count}. Woops - we've got a leak.
And yes, that leak had been there since long (I'm afraid that "long" may
be something about '93). Oh, well, one more race that needs fixing...
-
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/
This archive was generated by hypermail 2b29 : Sat Aug 05 2000 - 21:24:11 EDT