Hugh Dickins e1f1b1572e mm/huge_memory.c: fix data loss when splitting a file pmd
__split_huge_pmd_locked() must check if the cleared huge pmd was dirty,
and propagate that to PageDirty: otherwise, data may be lost when a huge
tmpfs page is modified then split then reclaimed.

How has this taken so long to be noticed?  Because there was no problem
when the huge page is written by a write system call (shmem_write_end()
calls set_page_dirty()), nor when the page is allocated for a write fault
(fault_dirty_shared_page() calls set_page_dirty()); but when allocated for
a read fault (which MAP_POPULATE simulates), no set_page_dirty().

Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1807111741430.1106@eggly.anvils
Fixes: d21b9e57c74c ("thp: handle file pages in split_huge_pmd()")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Ashwin Chaugule <ashwinch@google.com>
Reviewed-by: Yang Shi <yang.shi@linux.alibaba.com>
Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: <stable@vger.kernel.org>	[4.8+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-07-21 12:50:46 -07:00
..
2018-06-07 17:34:36 -07:00
2018-06-05 13:24:20 -07:00
2018-06-08 17:21:52 -07:00
2017-11-15 18:21:05 -08:00
2018-04-11 10:28:39 -07:00
2018-06-07 17:34:35 -07:00
2018-06-15 07:55:25 +09:00
2018-06-07 17:34:35 -07:00
2018-04-11 10:28:32 -07:00
2018-06-07 17:34:36 -07:00
2018-06-15 07:55:25 +09:00
2018-06-07 17:34:36 -07:00
2018-04-20 17:18:35 -07:00
2018-06-15 07:55:25 +09:00
2018-06-12 16:19:22 -07:00
2018-04-11 10:28:39 -07:00
2018-06-07 17:34:36 -07:00
2018-04-11 10:28:39 -07:00
2018-05-11 17:28:45 -07:00
2018-02-06 18:32:48 -08:00
2018-06-15 07:55:25 +09:00