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: <20150815153713.GB22485@thunk.org>
Date:	Sat, 15 Aug 2015 11:37:13 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	kernel-janitors@...r.kernel.org
Subject: Re: [patch 1/2 v2] ext4: simplify some code in read_mmp_block()

On Fri, Aug 14, 2015 at 11:03:46AM -0600, Andreas Dilger wrote:
> > My static check complains because we have:
> > 
> > 	if (!*bh)
> > 		return -ENOMEM;
> > 	if (*bh) {
> > 
> > The second check is unnecessary.
> > 
> > I've simplified this code by moving the "if (!*bh)" checks around.  Also
> > Andreas Dilger says we should probably print a warning if sb_getblk()
> > fails.
> > 
> > Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
> 
> Reviewed-by: Andreas Dilger <adilger@...ger.ca>

Applied, thanks.  I've changed the patch slightly to also print a
warning if the MMP magic number and/or checksum for the MMP block
doesn't check out, and to print the error code to disambiguate between
the various failure cases.

One thing, from looking at the function --- it looks like it might be
a good idea if we were to move the call to clear_buffer_uptodate() to
*after* the sb_getblk() call, no?

Otherwise we don't reread the MMP block if it is already in the cache,
and it is the first time read_mmp_block() is called in a function in
fs/ext4/mmp.c.....

							- 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