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: <20140708115827.GB27440@thunk.org>
Date:	Tue, 8 Jul 2014 07:58:27 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Андрей Василишин 
	<a.vasilishin@....ua>, Jon Severinsson <jon@...erinsson.net>,
	744953@...s.debian.org
Subject: Re: [PATCH] e2fsck: reopen the file system with saved flags after a
 journal replay

On Tue, Jul 08, 2014 at 11:03:53AM +0200, Lukáš Czerner wrote:
> > +	ctx->openfs_flags = flags;
> >  	retval = try_open_fs(ctx, flags, io_ptr, &fs);
> 
> Maybe we can get rid of 'flags' argument since it's not needed
> anymore ?

Yeah, I thought of that, but I was trying to keep the patch small,
since I thought this was one that distros might want to cherry pick.

> Otherwise the patch looks good, however for some reason I can not
> reproduce the problem in the big file system (without bigalloc) even
> though looking at bitmap.c it looks like we really should get that
> error.

Ah, yes, in the big file system case we don't hit it because we don't
actually load the bitmaps before we close and reopen the file system
again.  But in the bigalloc case, we check and fail at openfs time,
which aborts the fsck run.

So we could work around this by moving the bigalloc check to when we
open the file system, but you want get the other openfs flags right,
especially the EXT2_FLAG_SKIP_MMP flags.

Cheers,

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