On Tue, Feb 18, 2020 at 11:04:26PM -0500, Qian Cai wrote: > inode::i_size could be accessed concurently as noticed by KCSAN, > > BUG: KCSAN: data-race in iomap_do_writepage / iomap_write_end > > The write is protected by exclusive inode::i_rwsem (in > xfs_file_buffered_aio_write()) but the read is not. A shattered value > could introduce a logic bug. Fixed it using a pair of WRITE/READ_ONCE(). We had a different problem with lack of READ_ONCE/WRITE_ONCE for i_size, the fix was the same though. There was i_size_read(inode) used in max() macro and compiled code two reads (unlocked), and this led to a race when where different value was checked and then used. The thread: https://lore.kernel.org/linux-fsdevel/20191011202050.8656-1-josef@xxxxxxxxxxxxxx/ We had to apply a workaround to btrfs code because the generic fix was not merged, even with several reviews and fixing a real bug. The report from KCSAN seems to require some sort of splitting the values. What we saw happened on 64bit platform without that effect so I'd call that a more likely to happen because the pattern max(i_size_read(inode), ...) is not something we'd instinctively consider unsafe.
