linux-ext4 - Re: [patch 1/2 v2] ext4: simplify some code in read_mmp

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