linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Theodore Tso <tytso@mit.edu>
Cc: cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [RFC PATCH -v2 8/9] ext4: Fix double free of blocks
Date: Wed, 5 Nov 2008 20:55:47 +0530	[thread overview]
Message-ID: <20081105152547.GD6244@skywalker> (raw)
In-Reply-To: <20081104164604.GK30291@mit.edu>

On Tue, Nov 04, 2008 at 11:46:04AM -0500, Theodore Tso wrote:
> On Mon, Nov 03, 2008 at 11:06:08PM +0530, Aneesh Kumar K.V wrote:
> > blocks freed but not yet committed will be marked free
> > in disk bitmap. We need to consider them as used when
> > releasing inode prealloc space. Otherwise we would
> > double free them via mb_free_blocks
> 
> Stupid question...   
> 
> Blocks that are added to an inode's preallocation list were initially
> free, right?  And once they are in the inode's preallocation they are
> marked in use by mballoc, so they can't be allocated for another
> inode.  If a block in the preallocation list is used, it's removed
> from the preallocation line.  So even if that inode is subsequented
> unlinked or truncated, I'm curious how the double free situation
> happens in the first place.
> 
> What am I missing?
> 

We we discard  inode preallocation we look at the block bitmap
and mark the blocks found free in the bitmap using mb_free_blocks.
Now if we  allocate some blocks and later free some of them we would
have called ext4_mb_free blocks on them which mean we would have
marked the blocks free on bitmap. Now on file close we release
inode pa. We look at the block bitmap and if the block is free
in bitmap we call mb_free_blocks. Also on committing the transaction we
call mb_free_blocks on them. To avoid the above we need to make sure
when we discard_inode_pa we look at a bitmap that have block freed
and not yet committed as used.

-aneesh

  reply	other threads:[~2008-11-05 15:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-03 17:36 [RFC PATCH -v2 1/9] ext4: sparse fixes Aneesh Kumar K.V
2008-11-03 17:36 ` [RFC PATCH -v2 2/9] ext4: Add blocks added during resize to bitmap Aneesh Kumar K.V
2008-11-03 17:36   ` [RFC PATCH -v2 3/9] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize Aneesh Kumar K.V
2008-11-03 17:36     ` [RFC PATCH -v2 4/9] ext4: cleanup mballoc header files Aneesh Kumar K.V
2008-11-03 17:36       ` [RFC PATCH -v2 5/9] ext4: sparse annotate the group info semaphore Aneesh Kumar K.V
2008-11-03 17:36         ` [RFC PATCH -v2 6/9] ext4: Call journal commit callback without holding j_list_lock Aneesh Kumar K.V
2008-11-03 17:36           ` [RFC PATCH -v2 7/9] ext4: don't use the block freed but not yet committed during buddy initialization Aneesh Kumar K.V
2008-11-03 17:36             ` [RFC PATCH -v2 8/9] ext4: Fix double free of blocks Aneesh Kumar K.V
2008-11-03 17:36               ` [RFC PATCH -v2 9/9] ext4: Fix lockdep recursive locking warning Aneesh Kumar K.V
2008-11-04 18:15                 ` Theodore Tso
2008-11-04 16:46               ` [RFC PATCH -v2 8/9] ext4: Fix double free of blocks Theodore Tso
2008-11-05 15:25                 ` Aneesh Kumar K.V [this message]
2008-11-04 17:15             ` [RFC PATCH -v2 7/9] ext4: don't use the block freed but not yet committed during buddy initialization Theodore Tso
2008-11-05 15:23               ` Aneesh Kumar K.V
2008-11-04 17:37           ` [RFC PATCH -v2 6/9] ext4: Call journal commit callback without holding j_list_lock Theodore Tso
2008-11-04 18:13           ` Theodore Tso
2008-11-04 17:43         ` [RFC PATCH -v2 5/9] ext4: sparse annotate the group info semaphore Theodore Tso
2008-11-05 14:59           ` Aneesh Kumar K.V
2008-11-04 18:00     ` [RFC PATCH -v2 3/9] ext4: Use EXT4_GROUP_INFO_NEED_INIT_BIT during resize Theodore Tso
2008-11-05 14:57       ` Aneesh Kumar K.V
2008-11-04 18:02 ` [RFC PATCH -v2 1/9] ext4: sparse fixes Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081105152547.GD6244@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).