From: Eric Sandeen Date: Thu, 6 Feb 2014 05:43:17 +0000 (+1100) Subject: xfs/008: initialize "valid" bitmap in randholes.c X-Git-Tag: v2022.05.01~3253 X-Git-Url: http://git.apps.os.sepia.ceph.com/?p=xfstests-dev.git;a=commitdiff_plain;h=9d00bf83d2311ba52128d8c966a8a4ad12b74a8f xfs/008: initialize "valid" bitmap in randholes.c 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...? [ dchinner explains during review: 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 and those 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... ] Signed-off-by: Eric Sandeen Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner --- diff --git a/src/randholes.c b/src/randholes.c index 5ad602ea..ee5b6b66 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;