Message ID | 20081203195618.GI8950@kroah.com |
---|---|
State | Not Applicable, archived |
Headers | show |
On Wed, Dec 03, 2008 at 11:56:18AM -0800, Greg KH wrote:
> 2.6.27-stable review patch. If anyone has any objections, please let us know.
Turns out this patch introduces a worse regression than it fixes. The
bug that the patches fixes is that on-line resizes of filesystems with
a 1k blocksize will usually fail. The regression is that when a
filesystem with 1k blocksize is stressed, the filesystem can get
corrupted. On balance, on-line resizing failing is less of a disaster
than corrupting the filesystem when its stressed. Fortunately, it's
only an issue when the filesystem blocksize is less than the page
size, which isn't the common case at least for the x86.
There are patches queued up to address this, but they haven't hit
mainline yet. Probably best to pull this from the stable tree for
now.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 03, 2008 at 11:10:16PM -0500, Theodore Tso wrote: > On Wed, Dec 03, 2008 at 11:56:18AM -0800, Greg KH wrote: > > 2.6.27-stable review patch. If anyone has any objections, please let us know. > > Turns out this patch introduces a worse regression than it fixes. The > bug that the patches fixes is that on-line resizes of filesystems with > a 1k blocksize will usually fail. The regression is that when a > filesystem with 1k blocksize is stressed, the filesystem can get > corrupted. On balance, on-line resizing failing is less of a disaster > than corrupting the filesystem when its stressed. Fortunately, it's > only an issue when the filesystem blocksize is less than the page > size, which isn't the common case at least for the x86. > > There are patches queued up to address this, but they haven't hit > mainline yet. Probably best to pull this from the stable tree for > now. Thanks for letting me know, I've now dropped it from this release. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -318,9 +318,11 @@ ext4_read_block_bitmap(struct super_bloc 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); --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -115,9 +115,11 @@ ext4_read_inode_bitmap(struct super_bloc 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); --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -784,9 +784,11 @@ static int ext4_mb_init_cache(struct pag 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],