[PATCH] xfstests: initialize "valid" bitmap in randholes.c

[PATCH] xfstests: initialize "valid" bitmap in randholes.c

[Eric Sandeen]

Failures were reported in xfs/008 on s390; dchinner suggested that
perhaps the uninitialized "valid" bitmap was behaving differently on
that platform, and sure enough, this patch fixes things up.

TBH, I'm not sure why using an uninitialized bitmap worked at
all, ever, anywhere...?

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

diff --git a/src/randholes.c b/src/randholes.c
index 5ad602e..ee5b6b6 100644
--- a/src/randholes.c
+++ b/src/randholes.c
@@ -437,6 +437,7 @@ main(int argc, char *argv[])
 		perror("malloc");
 		return 1;
 	}
+	memset(valid, 0, size);
 
 	/* Lots of arguments affect how we open the file */
 	oflags = test ? O_RDONLY : O_RDWR|O_CREAT;

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

Re: [PATCH] xfstests: initialize "valid" bitmap in randholes.c

[Dave Chinner]

On Wed, Feb 05, 2014 at 12:35:55PM -0600, Eric Sandeen wrote:
> Failures were reported in xfs/008 on s390; dchinner suggested that
> perhaps the uninitialized "valid" bitmap was behaving differently on
> that platform, and sure enough, this patch fixes things up.
> 
> TBH, I'm not sure why using an uninitialized bitmap worked at
> all, ever, anywhere...?

It depends on glibc behaviour to whether newly allocated memory is
zeroed or not. e.g. for large allocations glibc uses
mmap() to directly map anonymous pages for the allocation. These get
zeroed by the kernel before being mapped into the user address
space. If glibc allocates from the heap and needs to grow it, it
uses sbrk() to grow the heap an dthose pages are, again, zeroed by
the kernel. However, if the allocation comes from the heap from
previously freed memory, then it doesn't get zeroed.

I'd say that the 3rd case is occurring here - there's memory that is
allocated and freed as part of the program startup that the bitmap
is being allocated from, and so it's not newly zeroed pages that it
is being allocated from...

Regardless of the cause, the fix looks good.

Reviewed-by: Dave Chinner <dchinner@redhat.com>

-- 
Dave Chinner
david@fromorbit.com

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