linux-ext4 - Re: + ext3-fix-online-resize-bug.patch added to -mm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20080603204208.GF2961@webber.adilger.int>
Date:	Tue, 03 Jun 2008 14:42:08 -0600
From:	Andreas Dilger <adilger@....com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	jbacik@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: + ext3-fix-online-resize-bug.patch added to -mm tree

On Jun 02, 2008  17:22 -0700, Andrew Morton wrote:
> > ------------------------------------------------------
> > Subject: ext3: fix online resize bug
> > From: Josef Bacik <jbacik@...hat.com>
> > 
> > There is a bug when we are trying to verify that the reserve inode's
> > double indirect blocks point back to the primary gdt blocks.  The fix is
> > obvious, we need to mod the gdb count by the addr's per block.  You can
> > verify this with the following test case
> > 
> > dd if=/dev/zero of=disk1 seek=1024 count=1 bs=100M
> > losetup /dev/loop1 disk1
> > pvcreate /dev/loop1
> > vgcreate loopvg1 /dev/loop1
> > lvcreate -l 100%VG loopvg1 -n looplv1
> > mkfs.ext3 -J size=64 -b 1024 /dev/loopvg1/looplv1
> > mount /dev/loopvg1/looplv1 /mnt/loop
> > dd if=/dev/zero of=disk2 seek=1024 count=1 bs=50M
> > losetup /dev/loop2 disk2
> > pvcreate /dev/loop2
> > vgextend loopvg1 /dev/loop2
> > lvextend -l 100%VG /dev/loopvg1/looplv1
> > resize2fs /dev/loopvg1/looplv1
> > 
> > without this patch the resize2fs fails, with it the resize2fs succeeds.
> > 
> 
> Could I please gather some reviews and ackings on this?

You can add a Signed-off-by: Andreas Dilger <adilger@....com>
The wrapping is clearly correct, because the end of the res = 0 loop
is itself wrapping "data" after it exceeds "end".  The current code is
just broken if data >= end to start with.

> Also, do we think it is 2.6.25.x material?

It definitely contains no risk unless you are doing an online resize.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html