Re: Odd "leak" of extent info into data blocks?

[Theodore Tso <tytso@mit.edu>]

On Tue, Sep 08, 2009 at 02:18:35PM -0700, Curt Wohlgemuth wrote:
> 
> All bforget() does is clear the buffer's dirty bit.  Meanwhile, the
> page is still marked dirty, and can be in the middle of writeback;
> it's true that __block_write_full_page() will check the dirty bit for
> each buffer in the page, but there doesn't seem to be any
> synchronization to ensure that the write won't take place at some
> point in time after bforget() is called.  Which means it can be called
> after the bitmap is changed.

Let me make sure I got this right.  The problem that you're worried
about is a block that had previously contained an extent tree node for
an inode that gets deleted, and then that blocks gets reallocated for
use as a data block.  In ext3 and ext4, metadata blocks (such as
extent tree blocks), aren't stored in the page cache.

So I'm not sure why you're worried about the page being marked dirty.
What's the scenario you are concerned about?

If it's the case where a data block for a deleted inode getting
rewritten after the inode is deleted, when the inode is deleted,
truncate_inode_apges() end up dropping the pages from the page cache
*before* the block allocation bitmap is dropped.

> This is why I opted to wait for the buffer to be written out before
> continuing on to ext4_free_blocks().

Just to be clear, which buffer are you talking about here?

     	   	  	       	       - Ted