All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] libxfs: don't write uninitialized heap contents into new directory blocks
Date: Thu, 19 Mar 2015 14:28:34 -0400	[thread overview]
Message-ID: <20150319182834.GI11669@laptop.bfoster> (raw)
In-Reply-To: <20150318232159.GA24608@birch.djwong.org>

On Wed, Mar 18, 2015 at 04:21:59PM -0700, Darrick J. Wong wrote:
> When we're initializing a new directory block, zero the buffer
> contents to avoid writing random heap contents (and crc thereof)
> to disk.  This eliminates a few valgrind complaints in xfs_repair.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---

Well it seems Ok to me:

Reviewed-by: Brian Foster <bfoster@redhat.com>

... but I do notice that we start ending up with multiple memset() calls
throughout these codepaths. E.g., xfs_dir3_data_init() memsets the
target bytes for the header if crc is enabled, xfs_dir3_leaf_get_buf()
calls xfs_dir3_leaf_init() which does something similar, etc.

I wonder if we should just zero the buffer content unconditionally on
allocation?

Brian

>  libxfs/xfs_da_btree.c  |    1 +
>  libxfs/xfs_dir2_data.c |    1 +
>  libxfs/xfs_dir2_leaf.c |    1 +
>  libxfs/xfs_dir2_node.c |    2 +-
>  4 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libxfs/xfs_da_btree.c b/libxfs/xfs_da_btree.c
> index b731b54..bc73cbc 100644
> --- a/libxfs/xfs_da_btree.c
> +++ b/libxfs/xfs_da_btree.c
> @@ -562,6 +562,7 @@ xfs_da3_root_split(
>  	if (error)
>  		return error;
>  	node = bp->b_addr;
> +	memset(bp->b_addr, 0, bp->b_bcount);
>  	oldroot = blk1->bp->b_addr;
>  	if (oldroot->hdr.info.magic == cpu_to_be16(XFS_DA_NODE_MAGIC) ||
>  	    oldroot->hdr.info.magic == cpu_to_be16(XFS_DA3_NODE_MAGIC)) {
> diff --git a/libxfs/xfs_dir2_data.c b/libxfs/xfs_dir2_data.c
> index dc9df4d..79c2fc2 100644
> --- a/libxfs/xfs_dir2_data.c
> +++ b/libxfs/xfs_dir2_data.c
> @@ -559,6 +559,7 @@ xfs_dir3_data_init(
>  		XFS_DATA_FORK);
>  	if (error)
>  		return error;
> +	memset(bp->b_addr, 0, bp->b_bcount);
>  	bp->b_ops = &xfs_dir3_data_buf_ops;
>  	xfs_trans_buf_set_type(tp, bp, XFS_BLFT_DIR_DATA_BUF);
>  
> diff --git a/libxfs/xfs_dir2_leaf.c b/libxfs/xfs_dir2_leaf.c
> index 8e0cbc9..6eb03fc 100644
> --- a/libxfs/xfs_dir2_leaf.c
> +++ b/libxfs/xfs_dir2_leaf.c
> @@ -382,6 +382,7 @@ xfs_dir3_leaf_get_buf(
>  	if (error)
>  		return error;
>  
> +	memset(bp->b_addr, 0, bp->b_bcount);
>  	xfs_dir3_leaf_init(mp, tp, bp, dp->i_ino, magic);
>  	xfs_dir3_leaf_log_header(tp, bp);
>  	if (magic == XFS_DIR2_LEAF1_MAGIC)
> diff --git a/libxfs/xfs_dir2_node.c b/libxfs/xfs_dir2_node.c
> index 3737e4e..3e2f04d 100644
> --- a/libxfs/xfs_dir2_node.c
> +++ b/libxfs/xfs_dir2_node.c
> @@ -247,7 +247,7 @@ xfs_dir3_free_get_buf(
>  	 * Initialize the new block to be empty, and remember
>  	 * its first slot as our empty slot.
>  	 */
> -	memset(bp->b_addr, 0, sizeof(struct xfs_dir3_free_hdr));
> +	memset(bp->b_addr, 0, bp->b_bcount);
>  	memset(&hdr, 0, sizeof(hdr));
>  
>  	if (xfs_sb_version_hascrc(&mp->m_sb)) {
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-03-19 18:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 23:21 [PATCH] libxfs: don't write uninitialized heap contents into new directory blocks Darrick J. Wong
2015-03-19 18:28 ` Brian Foster [this message]
2015-03-19 21:02   ` Darrick J. Wong
2015-03-19 22:59     ` Dave Chinner
2015-03-19 23:25       ` Darrick J. Wong
2015-03-19 23:37         ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150319182834.GI11669@laptop.bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.