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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 3 Jun 2008 13:54:01 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andreas Dilger <adilger@....com>
Cc:	jbacik@...hat.com, linux-ext4@...r.kernel.org
Subject: Re: + ext3-fix-online-resize-bug.patch added to -mm tree

On Tue, 03 Jun 2008 14:42:08 -0600
Andreas Dilger <adilger@....com> wrote:

> 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.

OK, thanks.

I made that an Acked-by: (as per Documentation/SubmittingPatches).  I
could have made it a Reviewed-by: (which is stronger) but whatever.

> > Also, do we think it is 2.6.25.x material?
> 
> It definitely contains no risk unless you are doing an online resize.

That didn't answer my question ;)
--
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

Powered by blists - more mailing lists