The $dread_pid refers to the while-true-do loop, wait for $dread_pid
doesn't mean the xfs_io direct read process is already dead,
sometimes xfs_io process is still running and blocking
_scratch_unmount.
Fix it by making the direct read does a fixed number of loop and
break out the second mmap-fpunch loop if the first loop exits. At
this point we're sure that there's no unfinished background process
blocking the umount.
Reviewed-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test reproduces a race between a direct I/O read and
a mapped write to a hole in a file. On xfs filesystem, it
will trigger a BUG_ON(), and this XFS bug has been fixed by:
04197b3 ("xfs: don't BUG() on mixed direct and mapped I/O")
[ eguan: umount before check dmesg log, and add rw group ]
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Eryu Guan
Xiao Yang