Hi Jan, On 10/25/21 11:13 PM, Jan Kara wrote: > ocfs2_truncate_file() did unmap invalidate page cache pages before > zeroing partial tail cluster and setting i_size. Thus some pages could > be left (and likely have left if the cluster zeroing happened) in the > page cache beyond i_size after truncate finished letting user possibly > see stale data once the file was extended again. Also the tail cluster I don't quite understand the case. truncate_inode_pages() will truncate pages from new_i_size to i_size, and the following ocfs2_orphan_for_truncate() will zero range and then update i_size for inode as well as dinode. So once truncate finished, how stale data exposing happens? Or do you mean a race case between the above two steps? Thanks, Joseph > zeroing was not guaranteed to finish before truncate finished causing > possible stale data exposure. The problem started to be particularly > easy to hit after commit 6dbf7bb55598 "fs: Don't invalidate page buffers > in block_write_full_page()" stopped invalidation of pages beyond i_size > from page writeback path. > > Fix these problems by unmapping and invalidating pages in the page cache > after the i_size is reduced and tail cluster is zeroed out.
