On Wednesday 14 June 2017 07:21 PM, Kirill A. Shutemov wrote:
Hi,
Vlastimil noted that pmdp_invalidate() is not atomic and we can loose
dirty and access bits if CPU sets them after pmdp dereference, but
before set_pmd_at().
The bug doesn't lead to user-visible misbehaviour in current kernel, but
fixing this would be critical for future work on THP: both huge-ext4 and THP
swap out rely on proper dirty tracking.
Unfortunately, there's no way to address the issue in a generic way. We need to
fix all architectures that support THP one-by-one.
All architectures that have THP supported have to provide atomic
pmdp_invalidate(). If generic implementation of pmdp_invalidate() is used,
architecture needs to provide atomic pmdp_mknonpresent().
I've fixed the issue for x86, but I need help with the rest.
So far THP is supported on 8 architectures. Power and S390 already provides
atomic pmdp_invalidate(). x86 is fixed by this patches, so 5 architectures
left:
- arc;
- arm;
- arm64;
- mips;
- sparc -- it has custom pmdp_invalidate(), but it's racy too;
Please, help me with them.
Kirill A. Shutemov (3):
x86/mm: Provide pmdp_mknotpresent() helper
mm: Do not loose dirty and access bits in pmdp_invalidate()
mm, thp: Do not loose dirty bit in __split_huge_pmd_locked()
But in __split_huge_pmd_locked() we collected the dirty bit early. So
even if we made pmdp_invalidate() atomic, if we had marked the pmd pte
entry dirty after we collected the dirty bit, we still loose it right ?
May be we should relook at pmd PTE udpate interface. We really need an
interface that can update pmd entries such that we don't clear it in
between. IMHO, we can avoid the pmdp_invalidate() completely, if we can
switch from a pmd PTE entry to a pointer to PTE page (pgtable_t). We
also need this interface to avoid the madvise race fixed by
https://lkml.kernel.org/r/20170302151034.27829-1-kirill.shutemov@xxxxxxxxxxxxxxx
The usage of pmdp_invalidate while splitting the pmd also need updated
documentation. In the earlier version of thp, we were required to keep
the pmd present and marked splitting, so that code paths can wait till
the splitting is done.
With the current design, we can ideally mark the pmdp not present early
on right ? As long as we hold the pmd lock a parallel fault will try to
mark the pmd accessed and wait on the pmd lock. On taking the lock it
will find the pmd modified and we should retry access again ?
-aneesh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
