diff options
author | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-03-08 21:17:20 -0300 |
---|---|---|
committer | André Fabian Silva Delgado <emulatorman@parabola.nu> | 2016-03-08 21:17:20 -0300 |
commit | eccbe858ce6412b96fc7cb32eb23a3592f64e5f6 (patch) | |
tree | ed4f0e52d266bffc68a5b68afcfe69882b917efb /mm/memory.c | |
parent | 0c1ac6822620b9868cfad5b4c2c223c6cd6fbfd8 (diff) |
Linux-libre 4.4.4-gnupck-4.4.4-gnu
Diffstat (limited to 'mm/memory.c')
-rw-r--r-- | mm/memory.c | 14 |
1 files changed, 12 insertions, 2 deletions
diff --git a/mm/memory.c b/mm/memory.c index ec0b97379..0efd48e94 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3434,8 +3434,18 @@ static int __handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma, if (unlikely(pmd_none(*pmd)) && unlikely(__pte_alloc(mm, vma, pmd, address))) return VM_FAULT_OOM; - /* if an huge pmd materialized from under us just retry later */ - if (unlikely(pmd_trans_huge(*pmd))) + /* + * If a huge pmd materialized under us just retry later. Use + * pmd_trans_unstable() instead of pmd_trans_huge() to ensure the pmd + * didn't become pmd_trans_huge under us and then back to pmd_none, as + * a result of MADV_DONTNEED running immediately after a huge pmd fault + * in a different thread of this mm, in turn leading to a misleading + * pmd_trans_huge() retval. All we have to ensure is that it is a + * regular pmd that we can walk with pte_offset_map() and we can do that + * through an atomic read in C, which is what pmd_trans_unstable() + * provides. + */ + if (unlikely(pmd_trans_unstable(pmd))) return 0; /* * A regular pmd is established and it can't morph into a huge pmd |