A number of implementations of ->set_page_dirty check whether the page has been truncated (ie page->mapping has become NULL since entering set_page_dirty()). Several other implementations assume that they can do page->mapping->host to get to the inode. So either some implementations are doing unnecessary checks or others are vulnerable to a NULL pointer dereference if truncate() races with set_page_dirty(). I'm touching ->set_page_dirty() anyway as part of the page folio conversion. I'm thinking about passing in the mapping so there's no need to look at page->mapping. The comments on set_page_dirty() and set_page_dirty_lock() suggests there's no consistency in whether truncation is blocked or not; we're only guaranteed that the inode itself won't go away. But maybe the comments are stale. There're also some filesystems which always return false from set_page_dirty() and others which check for PageSwapCache, which surely can't happen. I'm also confused by the ones which set PageUptodate. And several should just use __set_page_dirty_no_writeback().
