I want to remove ->launder_folio. So I'm looking at commit e3db7691e9f3
which introduced ->launder_page. The race described there is pretty
clear:
invalidate_inode_pages2() may find the dirty bit has been set on a page
owing to the fact that the page may still be mapped after it was locked.
Only after the call to unmap_mapping_range() are we sure that the page
can no longer be dirtied.
ie this happens:
Task A Task B
mmaps a file, writes to page A
open(O_DIRECT)
read()
kiocb_invalidate_pages()
filemap_write_and_wait_range()
__filemap_fdatawrite_range()
filemap_fdatawrite_wbc()
do_writepages()
iomap_writepages()
write_cache_pages()
page A gets cleaned
writes to page A again
invalidate_inode_pages2_range()
folio_mapped() is true, so we unmap it
folio_launder() returns 0
invalidate_complete_folio2() returns 0
ret = -EBUSY
kiocb_invalidate_pages() returns EBUSY
and the DIO read fails, despite it being totally reasonable to return
the now-stale data on storage. A DIO write would be a different matter;
we really do need to get page A out of cache.
So would it be reasonable to unmap the pages earlier and rely on
invalidate_lock to prevent page faults making the page writable
between the call to filemap_write_and_wait_range() and the call to
invalidate_complete_folio2() ? Then we could get rid of ->launder_folio()
as well as making DIO a little more reliable when racing with page faults.
