path: root/.mailmap
diff options
authorJohannes Weiner <>2015-01-08 14:32:18 -0800
committerLinus Torvalds <>2015-01-08 15:10:51 -0800
commit2d6d7f98284648c5ed113fe22a132148950b140f (patch)
tree71cb2c508fa8eca681139ed84e123bd445ed48e3 /.mailmap
parent7a3ef208e662f4b63d43a23f61a64a129c525bbc (diff)
mm: protect set_page_dirty() from ongoing truncation
Tejun, while reviewing the code, spotted the following race condition between the dirtying and truncation of a page: __set_page_dirty_nobuffers() __delete_from_page_cache() if (TestSetPageDirty(page)) page->mapping = NULL if (PageDirty()) dec_zone_page_state(page, NR_FILE_DIRTY); dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); if (page->mapping) account_page_dirtied(page) __inc_zone_page_state(page, NR_FILE_DIRTY); __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE); which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE. Dirtiers usually lock out truncation, either by holding the page lock directly, or in case of zap_pte_range(), by pinning the mapcount with the page table lock held. The notable exception to this rule, though, is do_wp_page(), for which this race exists. However, do_wp_page() already waits for a locked page to unlock before setting the dirty bit, in order to prevent a race where clear_page_dirty() misses the page bit in the presence of dirty ptes. Upgrade that wait to a fully locked set_page_dirty() to also cover the situation explained above. Afterwards, the code in set_page_dirty() dealing with a truncation race is no longer needed. Remove it. Reported-by: Tejun Heo <> Signed-off-by: Johannes Weiner <> Acked-by: Kirill A. Shutemov <> Reviewed-by: Jan Kara <> Cc: <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions