On 2020/1/9 0:22, Darrick J. Wong wrote:
> TBH I've wondered if blocktrash -3 and fuzz-random should snapshot the
> buffer before randomizing it and try again if the contents don't change?
> I suspect most of our fuzz tests expect "randomize the ____" to return
> with ____ full of random junk, not the exact same contents as before.

In order to figure out how blocktrash works, I modified xfs/126:
@@ -72,7 +72,14 @@ echo "+ corrupt xattr"
  loff=1
  while true; do
         _scratch_xfs_db -x -c "inode ${inode}" -c "ablock ${loff}" -c 
"stack" | grep -q 'file attr block is unmapped' && break
+       tmp=`_scratch_xfs_db -x -c "inode ${inode}" -c "ablock ${loff}" 
-c "stack"`
+       tmp=${tmp#*fsbno }
+       fsbno=${tmp%)*}
+       _scratch_xfs_db -x -c "fsblock $fsbno" -c "p" &> /tmp/old
         _scratch_xfs_db -x -c "inode ${inode}" -c "ablock ${loff}" -c 
"stack" -c "blocktrash -x 32 -y $((blksz * 8)) -z ${FUZZ_ARGS}" >> 
$seqres.full
+       _scratch_xfs_db -x -c "fsblock $fsbno" -c "p" &> /tmp/new
+       echo "========================"
+       diff -y /tmp/old /tmp/new
         loff="$((loff + 1))"
  done


And in the normal case, I got the result as shown in "126.out.good".
On the other hand, if I add "-s 0" when blocktrash is performed, corrupt 
xattr will failed, and the result is in "126.out.bad".

It seems that in the attr block, there are some range that the content 
is 0, and if blocktrash happens to modify within the range, corrupt 
xattr will fail.

Maybe we can save the contents in the block before blocktrash is 
preformed, and try again if the non-zero range is the same. However, I'm 
not sure about the foundation of this phenomenon.

Thanks!
Yu Kuai