[old race caught] Re: BUG in ext2

[Alexander Viro]

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...