From: Andrea Arcangeli <aarcange@redhat.com>
To: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: 'Andrew Morton' <akpm@linux-foundation.org>,
linux-mm@kvack.org, 'Rik van Riel' <riel@redhat.com>,
'Hugh Dickins' <hughd@google.com>,
'Mel Gorman' <mgorman@techsingularity.net>
Subject: Re: [PATCH 1/4] mm: vm_page_prot: update with WRITE_ONCE/READ_ONCE
Date: Thu, 22 Sep 2016 21:15:56 +0200 [thread overview]
Message-ID: <20160922191556.GF3485@redhat.com> (raw)
In-Reply-To: <002e01d214a1$6f39e100$4dada300$@alibaba-inc.com>
Hello Hillf,
On Thu, Sep 22, 2016 at 03:17:52PM +0800, Hillf Danton wrote:
> Hey Andrea
> >
> > @@ -111,13 +111,16 @@ static pgprot_t vm_pgprot_modify(pgprot_t oldprot, unsigned long vm_flags)
> > void vma_set_page_prot(struct vm_area_struct *vma)
> > {
> > unsigned long vm_flags = vma->vm_flags;
> > + pgprot_t vm_page_prot;
> >
> > - vma->vm_page_prot = vm_pgprot_modify(vma->vm_page_prot, vm_flags);
> > + vm_page_prot = vm_pgprot_modify(vma->vm_page_prot, vm_flags);
> > if (vma_wants_writenotify(vma)) {
>
> Since vma->vm_page_prot is currently used in vma_wants_writenotify(), is
> it possible that semantic change is introduced here with local variable?
>From a short review I think you're right.
Writing an intermediate value with WRITE_ONCE before clearing
VM_SHARED wouldn't be correct either if the "vma" was returned by
vma_merge, so to fix this, the intermediate vm_page_prot needs to be
passed as parameter to vma_wants_writenotify(vma, vm_page_prot).
For now it's safer to drop this patch 1/4. The atomic setting of
vm_page_prot in mprotect is an orthogonal problem to the vma_merge
case8 issues in the other patches. The side effect would be the same
("next" vma ptes going out of sync with the write bit set, because
vm_page_prot was the intermediate value created with VM_SHARED still
set in vm_flags) but it's not a bug in vma_merge/vma_adjust here.
I can correct and resend this one later.
While at it, I've to say the handling of VM_SOFTDIRTY across vma_merge
also seems dubious when it's not mmap_region calling vma_merge but
that would be yet another third orthogonal problem, so especially that
one should be handled separately as it'd be specific to soft dirty
only, the atomicity issue above is somewhat more generic.
On a side note, the fix for vma_merge in -mm changes nothing in regard
of the above or soft dirty, they're orthogonal issues.
Thanks,
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-09-22 19:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 21:15 [PATCH 0/4] mm: vma_merge/vma_adjust minor updates against -mm Andrea Arcangeli
2016-09-21 21:15 ` [PATCH 1/4] mm: vm_page_prot: update with WRITE_ONCE/READ_ONCE Andrea Arcangeli
2016-09-22 7:17 ` Hillf Danton
2016-09-22 19:15 ` Andrea Arcangeli [this message]
2016-09-23 19:51 ` Andrea Arcangeli
2016-09-21 21:15 ` [PATCH 2/4] mm: vma_adjust: minor comment correction Andrea Arcangeli
2016-09-21 21:15 ` [PATCH 3/4] mm: vma_merge: correct false positive from __vma_unlink->validate_mm_rb Andrea Arcangeli
2016-09-21 21:15 ` [PATCH 4/4] mm: vma_adjust: remove superfluous confusing update in remove_next == 1 case Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160922191556.GF3485@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=riel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox