Re: [PATCH] xfsdump: Initialize getbmap structure in quantity2offset

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Aug 16, 2022 at 10:45:50AM +0200, Carlos Maiolino wrote:
> Prevent uninitialized data in the stack by initializing getbmap structure
> to zero.

The kernel should fill out all the bmap[1..BMAP_LEN-1] entries, right?

The only part of the array that's critical to initialize to a known
value is bmap[0], since that's what the kernel will read to decide what
to do, right?

Or, zooming out a bit, why did you decide to initialize the struct?  Was
it valgrind complaining about uninitialized ioctl memory, or did someone
report a bug?

(I'm actually fine with this change, I just want to know how you got
here. ;))

--D

> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
> 
> There is already a patch on the list to remove remaining DMAPI stuff from
> xfsdump:
> xfsdump: remove BMV_IF_NO_DMAPI_READ flag
> 
> This patch though, does not initialize the getbmap structure, and although
> the
> first struct in the array is initialized, the remaining structures in the
> array are not, leaving garbage in the stack.
> 
> 
>  dump/inomap.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/dump/inomap.c b/dump/inomap.c
> index f3200be..c4ea21d 100644
> --- a/dump/inomap.c
> +++ b/dump/inomap.c
> @@ -1627,7 +1627,7 @@ static off64_t
>  quantity2offset(jdm_fshandle_t *fshandlep, struct xfs_bstat *statp, off64_t qty)
>  {
>  	int fd;
> -	struct getbmap bmap[BMAP_LEN];
> +	struct getbmap bmap[BMAP_LEN] = {0};
>  	off64_t offset;
>  	off64_t offset_next;
>  	off64_t qty_accum;
> 
>