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]
Date:	Sun, 14 Sep 2014 10:50:52 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	TR Reardon <thomas_reardon@...mail.com>
Cc:	"tytso@....edu" <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 19/34] resize2fs: convert fs to and from 64bit mode

On Sun, Sep 14, 2014 at 01:34:14PM -0400, TR Reardon wrote:
> > Subject: [PATCH 19/34] resize2fs: convert fs to and from 64bit mode
> > From: darrick.wong@...cle.com
> > To: tytso@....edu; darrick.wong@...cle.com
> > CC: linux-ext4@...r.kernel.org
> > Date: Sat, 13 Sep 2014 15:13:18 -0700
> >
> > resize2fs does its magic by loading a filesystem, duplicating the
> > in-memory image of that fs, moving relevant blocks out of the way of
> > whatever new metadata get created, and finally writing everything back
> > out to disk. Enabling 64bit mode enlarges the group descriptors,
> > which makes resize2fs a reasonable vehicle for taking care of the rest
> > of the bookkeeping requirements, so add to resize2fs the ability to
> > convert a filesystem to 64bit mode and back.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@...cle.com>
> > ---
> > resize/main.c | 40 ++++++
> > resize/resize2fs.8.in | 18 +++
> > resize/resize2fs.c | 326 ++++++++++++++++++++++++++++++++++++++++++++++++-
> > resize/resize2fs.h | 3
> > 4 files changed, 379 insertions(+), 8 deletions(-)
> >
> >
> > diff --git a/resize/main.c b/resize/main.c
> > index c107028..9fea3d8 100644
> > --- a/resize/main.c
> > +++ b/resize/main.c
> > @@ -42,7 +42,7 @@ static char *device_name, *io_options;
> > static void usage (char *prog)
> > {
> > fprintf (stderr, _("Usage: %s [-d debug_flags] [-f] [-F] [-M] [-P] "
> > - "[-p] device [new_size]\n\n"), prog);
> > + "[-p] device [-b|-s|new_size]\n\n"), prog);
> >
> > exit (1);
> > }
> > @@ -200,7 +200,7 @@ int main (int argc, char ** argv)
> > if (argc && *argv)
> > program_name = *argv;
> >
> > - while ((c = getopt (argc, argv, "d:fFhMPpS:")) != EOF) {
> > + while ((c = getopt(argc, argv, "d:fFhMPpS:bs")) != EOF) {
> > switch (c) {
> > case 'h':
> > usage(program_name);
> > @@ -226,6 +226,12 @@ int main (int argc, char ** argv)
> > case 'S':
> > use_stride = atoi(optarg);
> > break;
> > + case 'b':
> > + flags |= RESIZE_ENABLE_64BIT;
> > + break;
> > + case 's':
> > + flags |= RESIZE_DISABLE_64BIT;
> > + break;
> > default:
> > usage(program_name);
> > }
> > @@ -389,6 +395,10 @@ int main (int argc, char ** argv)
> > if (sys_page_size> fs->blocksize)
> > new_size &= ~((sys_page_size / fs->blocksize)-1);
> > }
> > + /* If changing 64bit, don't change the filesystem size. */
> > + if (flags & (RESIZE_DISABLE_64BIT | RESIZE_ENABLE_64BIT)) {
> > + new_size = ext2fs_blocks_count(fs->super);
> > + }
> > if (!EXT2_HAS_INCOMPAT_FEATURE(fs->super,
> > EXT4_FEATURE_INCOMPAT_64BIT)) {
> > /* Take 16T down to 2^32-1 blocks */
> > @@ -440,7 +450,31 @@ int main (int argc, char ** argv)
> > fs->blocksize / 1024, new_size);
> > exit(1);
> > }
> > - if (new_size == ext2fs_blocks_count(fs->super)) {
> > + if ((flags & RESIZE_DISABLE_64BIT) && (flags & RESIZE_ENABLE_64BIT)) {
> > + fprintf(stderr, _("Cannot set and unset 64bit feature.\n"));
> > + exit(1);
> > + } else if (flags & (RESIZE_DISABLE_64BIT | RESIZE_ENABLE_64BIT)) {
> > + new_size = ext2fs_blocks_count(fs->super);
> 
> 
> Redundant to assignment just above? 		 	   		  --

Yeah, I think so.  I think the original purpose was to reset new_size after the
size checks, but at the moment the only way that happens is if we've a 32bit FS
with exactly 2^32 blocks, which shouldn't be possible.

--D

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ