* [PATCH] mm: page_mkclean vs MADV_DONTNEED race
@ 2019-03-21 4:06 Aneesh Kumar K.V
2019-03-21 23:31 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Aneesh Kumar K.V @ 2019-03-21 4:06 UTC (permalink / raw)
To: akpm, Kirill A . Shutemov; +Cc: linux-mm, linux-kernel, Aneesh Kumar K.V
MADV_DONTNEED is handled with mmap_sem taken in read mode.
We call page_mkclean without holding mmap_sem.
MADV_DONTNEED implies that pages in the region are unmapped and subsequent
access to the pages in that range is handled as a new page fault.
This implies that if we don't have parallel access to the region when
MADV_DONTNEED is run we expect those range to be unallocated.
w.r.t page_mkclean we need to make sure that we don't break the MADV_DONTNEED
semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock.
This implies we skip the pmd if we temporarily mark pmd none. Avoid doing
that while marking the page clean.
Keep the sequence same for dax too even though we don't support MADV_DONTNEED
for dax mapping
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
fs/dax.c | 2 +-
mm/rmap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 01bfb2ac34f9..697bc2f59b90 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -814,7 +814,7 @@ static void dax_entry_mkclean(struct address_space *mapping, pgoff_t index,
goto unlock_pmd;
flush_cache_page(vma, address, pfn);
- pmd = pmdp_huge_clear_flush(vma, address, pmdp);
+ pmd = pmdp_invalidate(vma, address, pmdp);
pmd = pmd_wrprotect(pmd);
pmd = pmd_mkclean(pmd);
set_pmd_at(vma->vm_mm, address, pmdp, pmd);
diff --git a/mm/rmap.c b/mm/rmap.c
index b30c7c71d1d9..76c8dfd3ae1c 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -928,7 +928,7 @@ static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
continue;
flush_cache_page(vma, address, page_to_pfn(page));
- entry = pmdp_huge_clear_flush(vma, address, pmd);
+ entry = pmdp_invalidate(vma, address, pmd);
entry = pmd_wrprotect(entry);
entry = pmd_mkclean(entry);
set_pmd_at(vma->vm_mm, address, pmd, entry);
--
2.20.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] mm: page_mkclean vs MADV_DONTNEED race
2019-03-21 4:06 [PATCH] mm: page_mkclean vs MADV_DONTNEED race Aneesh Kumar K.V
@ 2019-03-21 23:31 ` Andrew Morton
2019-03-22 8:23 ` Aneesh Kumar K.V
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2019-03-21 23:31 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Kirill A . Shutemov, linux-mm, linux-kernel, Dan Williams,
Andrea Arcangeli
On Thu, 21 Mar 2019 09:36:10 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
> MADV_DONTNEED is handled with mmap_sem taken in read mode.
> We call page_mkclean without holding mmap_sem.
>
> MADV_DONTNEED implies that pages in the region are unmapped and subsequent
> access to the pages in that range is handled as a new page fault.
> This implies that if we don't have parallel access to the region when
> MADV_DONTNEED is run we expect those range to be unallocated.
>
> w.r.t page_mkclean we need to make sure that we don't break the MADV_DONTNEED
> semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock.
> This implies we skip the pmd if we temporarily mark pmd none. Avoid doing
> that while marking the page clean.
>
> Keep the sequence same for dax too even though we don't support MADV_DONTNEED
> for dax mapping
What were the runtime effects of the bug?
Did you consider a -stable backport?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] mm: page_mkclean vs MADV_DONTNEED race
2019-03-21 23:31 ` Andrew Morton
@ 2019-03-22 8:23 ` Aneesh Kumar K.V
0 siblings, 0 replies; 3+ messages in thread
From: Aneesh Kumar K.V @ 2019-03-22 8:23 UTC (permalink / raw)
To: Andrew Morton
Cc: Kirill A . Shutemov, linux-mm, linux-kernel, Dan Williams,
Andrea Arcangeli
Andrew Morton <akpm@linux-foundation.org> writes:
> On Thu, 21 Mar 2019 09:36:10 +0530 "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> wrote:
>
>> MADV_DONTNEED is handled with mmap_sem taken in read mode.
>> We call page_mkclean without holding mmap_sem.
>>
>> MADV_DONTNEED implies that pages in the region are unmapped and subsequent
>> access to the pages in that range is handled as a new page fault.
>> This implies that if we don't have parallel access to the region when
>> MADV_DONTNEED is run we expect those range to be unallocated.
>>
>> w.r.t page_mkclean we need to make sure that we don't break the MADV_DONTNEED
>> semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock.
>> This implies we skip the pmd if we temporarily mark pmd none. Avoid doing
>> that while marking the page clean.
>>
>> Keep the sequence same for dax too even though we don't support MADV_DONTNEED
>> for dax mapping
>
> What were the runtime effects of the bug?
The bug was noticed by code review and I didn't observe any failures
w.r.t test run. This is similar to
commit 58ceeb6bec86d9140f9d91d71a710e963523d063
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Thu Apr 13 14:56:26 2017 -0700
thp: fix MADV_DONTNEED vs. MADV_FREE race
commit ced108037c2aa542b3ed8b7afd1576064ad1362a
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Thu Apr 13 14:56:20 2017 -0700
thp: fix MADV_DONTNEED vs. numa balancing race
>
> Did you consider a -stable backport?
Considering nobody reported issues w.r.t MADV_DONTNEED I was not sure.
-aneesh
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-22 8:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-21 4:06 [PATCH] mm: page_mkclean vs MADV_DONTNEED race Aneesh Kumar K.V
2019-03-21 23:31 ` Andrew Morton
2019-03-22 8:23 ` Aneesh Kumar K.V
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).