In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix races between hole punching and AIO+DIO
After commit "ocfs2: return real error code in ocfs2diowrgetblock", fstests/generic/300 become from always failed to sometimes failed:
======================================================================== [ 473.293420 ] run fstests generic/300
[ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2changeextentflag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2markextentwritten:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2dioendiowrite:2374 ERROR: status = -3
In _blockdevdirectIO, ocfs2diowrgetblock is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2writebeginnolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2removeextent(). At end io worker thread, ocfs2searchextent_list found there is no such extent at the cpos.
T1 T2 T3
inode lock
...
insert extents
...
inode unlock
ocfs2fallocate _ocfs2changefilespace inode lock lock ipallocsem ocfs2removeinoderange inode ocfs2removebtreerange ocfs2removeextent ^---remove the extent at cpos 78723 ... unlock ipallocsem inode unlock ocfs2dioendio ocfs2dioendiowrite lock ipallocsem ocfs2markextentwritten ocfs2changeextentflag ocfs2searchextentlist ^---failed to find extent ... unlock ipalloc_sem
In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.