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:	Thu, 11 Dec 2014 21:02:49 -0800
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 09/47] libext2fs: use a dynamically sized (or
 caller-provided) block zeroing buffer

On Thu, Dec 11, 2014 at 09:37:56PM -0500, Theodore Ts'o wrote:
> On Fri, Nov 07, 2014 at 01:51:46PM -0800, Darrick J. Wong wrote:
> > Dynamically grow the block zeroing buffer to a maximum of 4MB, and
> > allow callers to provide their own zeroed buffer.
> > 
> > +
> > +	/* If the user gave us a buffer, write that out */
> > +	if (block_buf) {
> > +		retval = io_channel_write_blk64(fs->io, blk, num, block_buf);
> > +		if (retval) {
> > +			if (ret_count)
> > +				*ret_count = num;
> > +			if (ret_blk)
> > +				*ret_blk = blk;
> > +		}
> > +
> > +		return retval;
> > +	}
> 
> I've looked through the whole patch series,and there's only a single
> caller of the new ext2fs_zero_blocks3 function --- and the caller is
> going to be giving us a pre-zero'ed buffer, it might as well call
> io_channel_write_blk64() directly instead of the new
> ext2fs_zero_block3().  This is what we do in 1.42.x, and it makes a
> lot more sense than changing the code to call ext2fs_zero_blocks3(),
> and requiring it to depend on the caller having zero'ed the block
> buffer, and then adding absolutely no value other than calling
> i_channel_zeroout(), having it return UNIMPLEMENTED because it makes
> no sense to use BLKZEROOUT, and then falling back to
> io_channel_write_blk64().  
> 
> So what I think makes sense is to drop the new ext2fs_zero_blocks3()
> function, and to revert the change in ext2fs_alloc_block2() so that it
> calls io_channel_write_blk64() instead of ext2fs_zero_block2().
> 
> I'll take care of making this change in the patch.

Ok, thank you!

(Esp. since the power may or may not stay up out here in the West.)

--D

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