On Wed, Jun 29, 2022 at 11:45:47AM +0200, Jan Kara wrote: > So the only viable solution is really for the filesystem to detect such > unprotectable pages if it cares and somehow deal with them (skip writeback, > use bounce pages, ...). The good news is that we already have > page_maybe_dma_pinned() call that at least allows detection of such > unprotectable pages. The bad news is that page_maybe_dma_pinned only accounts for FOLL_PIN memory, and we till have a lot of users of FOLL_GET including direct I/O. Now for FOLL_PIN I think most problems would be solved by marking pages that are DMA pinned when writeback completes (that is when PG_writeback is cleared) dirty again, and making sure the equivalent of page_mkwrite is called for them again as well. The latter might be a bit ugly as PG_writeback could be cleared from interrupt context, even if most modern file systems especially if they do anything fancy like out of place writes or unwritten extents defer it to a workqueue. To reduce the overhead of this it would make sense to skip writing these pages back at all unless it is a data integrity write.
