linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Zhuravlev <Alex.Zhuravlev@Sun.COM>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Theodore Tso <tytso@MIT.EDU>,
	cmm@us.ibm.com, sandeen@redhat.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH -V2 3/5] ext4: Fix the race between read_block_bitmap and mark_diskspace_used
Date: Mon, 24 Nov 2008 21:41:20 +0300	[thread overview]
Message-ID: <492AF550.7000701@sun.com> (raw)
In-Reply-To: <20081124182132.GF8462@skywalker>

looks even more strange, IMHO. do I understand correct that two processes
doing allocation in the same group can do two initializations? what if one
process just allocated block(s) and not cleared UNINIT bit yet?

thanks, Alex



Aneesh Kumar K.V wrote:
> On Mon, Nov 24, 2008 at 09:17:53PM +0300, Alex Zhuravlev wrote:
>> Aneesh Kumar K.V wrote:
>>> With commit c806e68f we do a init_bitmap every time we do a
>>> read_block_bitmap.
>> can you explain why do we need to init it every time?
>>
> 
> The commit message  explains it well. It is because the buffer_head
> can be marked uptodate by a read from userspace. So we would skip doing
> a init_bitmap on the uninit group during resize.
> 
> commit c806e68f5647109350ec546fee5b526962970fd2
> Author: Frederic Bohe <frederic.bohe@bull.net>
> Date:   Fri Oct 10 08:09:18 2008 -0400
> 
>     ext4: fix initialization of UNINIT bitmap blocks
>     
>     This fixes a bug which caused on-line resizing of filesystems with a
>     1k blocksize to fail.  The root cause of this bug was the fact that if
>     an uninitalized bitmap block gets read in by userspace (which
>     e2fsprogs does try to avoid, but can happen when the blocksize is less
>     than the pagesize and an adjacent blocks is read into memory)
>     ext4_read_block_bitmap() was erroneously depending on the buffer
>     uptodate flag to decide whether it needed to initialize the bitmap
>     block in memory --- i.e., to set the standard set of blocks in use by
>     a block group (superblock, bitmaps, inode table, etc.).  Essentially,
>     ext4_read_block_bitmap() assumed it was the only routine that might
>     try to read a block containing a block bitmap, which is simply not
>     true.
>     
>     To fix this, ext4_read_block_bitmap() and ext4_read_inode_bitmap()
>     must always initialize uninitialized bitmap blocks.  Once a block or
>     inode is allocated out of that bitmap, it will be marked as
>     initialized in the block group descriptor, so in general this won't
>     result any extra unnecessary work.
>     
>     Signed-off-by: Frederic Bohe <frederic.bohe@bull.net>
>     Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> 
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index 59566c0..bd2ece2 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -319,9 +319,11 @@ ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group)
>  			    block_group, bitmap_blk);
>  		return NULL;
>  	}
> -	if (bh_uptodate_or_lock(bh))
> +	if (buffer_uptodate(bh) &&
> +	    !(desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)))
>  		return bh;
>  
> +	lock_buffer(bh);
>  	spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group));
>  	if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
>  		ext4_init_block_bitmap(sb, bh, block_group, desc);
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index 1343bf1..fe34d74 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -115,9 +115,11 @@ ext4_read_inode_bitmap(struct super_block *sb, ext4_group_t block_group)
>  			    block_group, bitmap_blk);
>  		return NULL;
>  	}
> -	if (bh_uptodate_or_lock(bh))
> +	if (buffer_uptodate(bh) &&
> +	    !(desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)))
>  		return bh;
>  
> +	lock_buffer(bh);
>  	spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group));
>  	if (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)) {
>  		ext4_init_inode_bitmap(sb, bh, block_group, desc);
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 335faee..b580714 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -782,9 +782,11 @@ static int ext4_mb_init_cache(struct page *page, char *incore)
>  		if (bh[i] == NULL)
>  			goto out;
>  
> -		if (bh_uptodate_or_lock(bh[i]))
> +		if (buffer_uptodate(bh[i]) &&
> +		    !(desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)))
>  			continue;
>  
> +		lock_buffer(bh[i]);
>  		spin_lock(sb_bgl_lock(EXT4_SB(sb), first_group + i));
>  		if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
>  			ext4_init_block_bitmap(sb, bh[i],


  parent reply	other threads:[~2008-11-24 18:41 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 16:44 [PATCH -V2 1/5] ext4: Remove unneeded code Aneesh Kumar K.V
2008-11-21 16:44 ` [PATCH -V2 2/5] ext4: unlock group before ext4_error Aneesh Kumar K.V
2008-11-21 16:44   ` [PATCH -V2 3/5] ext4: Fix the race between read_block_bitmap and mark_diskspace_used Aneesh Kumar K.V
2008-11-21 16:44     ` [PATCH -V2 4/5] ext4: Use both hi and lo bits of the group desc values Aneesh Kumar K.V
2008-11-21 16:44       ` [PATCH -V2 5/5] ext4: Fix the race between read_inode_bitmap and ext4_new_inode Aneesh Kumar K.V
2008-11-21 17:30         ` Eric Sandeen
2008-11-23 19:26         ` Theodore Tso
2008-11-24  4:05         ` Theodore Tso
2008-11-24 11:15           ` Aneesh Kumar K.V
2008-11-21 17:29       ` [PATCH -V2 4/5] ext4: Use both hi and lo bits of the group desc values Eric Sandeen
2008-11-21 17:41         ` Aneesh Kumar K.V
2008-11-21 17:53           ` Eric Sandeen
2008-11-23  4:09             ` Andreas Dilger
2008-11-24  1:21               ` Theodore Tso
2008-11-24  2:13           ` Theodore Tso
2008-11-24 10:38             ` Aneesh Kumar K.V
2008-11-21 17:22     ` [PATCH -V2 3/5] ext4: Fix the race between read_block_bitmap and mark_diskspace_used Eric Sandeen
2008-11-21 17:31       ` Aneesh Kumar K.V
2008-11-21 17:39         ` Aneesh Kumar K.V
2008-11-21 17:40           ` Eric Sandeen
2008-11-21 17:39         ` Eric Sandeen
2008-11-23 19:02         ` Theodore Tso
2008-11-24  6:40           ` Aneesh Kumar K.V
2008-11-23 14:00     ` Theodore Tso
2008-11-24  7:14       ` Alex Zhuravlev
2008-11-24 11:33         ` Aneesh Kumar K.V
2008-11-24 16:36           ` Alex Zhuravlev
2008-11-24 16:43             ` Aneesh Kumar K.V
2008-11-24 18:03               ` Alex Zhuravlev
2008-11-24 18:12                 ` Aneesh Kumar K.V
2008-11-24 18:17                   ` Alex Zhuravlev
2008-11-24 18:21                     ` Aneesh Kumar K.V
2008-11-24 18:28                       ` Alex Zhuravlev
2008-11-24 18:41                       ` Alex Zhuravlev [this message]
2008-11-25 14:29           ` Frédéric Bohé
2008-11-25 16:38             ` Alex Zhuravlev
2008-11-23 13:37   ` [PATCH -V2 2/5] ext4: unlock group before ext4_error Theodore Tso
2008-11-23 13:43     ` Theodore Tso
2008-11-23 13:59       ` Aneesh Kumar K.V
2008-11-21 17:20 ` [PATCH -V2 1/5] ext4: Remove unneeded code Eric Sandeen

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=492AF550.7000701@sun.com \
    --to=alex.zhuravlev@sun.com \
    --cc=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).