From: Oleg Nesterov <oleg@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roland Dreier <roland@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC] mm: account VMA before forced-COW via /proc/pid/mem
Date: Sat, 7 Apr 2012 19:33:18 +0200 [thread overview]
Message-ID: <20120407173318.GA5076@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1204062104090.4297@eggly.anvils>
On 04/06, Hugh Dickins wrote:
>
> I've long detested that behaviour of GUP write,force, and my strong
> preference would be not to layer more strangeness upon strangeness,
> but limit the damage by making GUP write,force fail in that case,
> instead of inserting a PageAnon page into a VM_SHARED mapping.
>
> I think it's unlikely that it will cause a regression in real life
> (it already fails if you did not open the mmap'ed file for writing),
Yes, and this is what looks confusing to me. Assuming I understand
you (and the code) correctly ;)
If we have a (PROT_READ, MAP_SHARED) file mapping, then FOLL_FORCE
works depending on "file->f_mode & FMODE_WRITE".
Afaics, because do_mmap_pgoff(MAP_SHARED) clears VM_MAYWRITE if
!FMODE_WRITE, and gup(FORCE) checks "vma->vm_flags & VM_MAYWRITE"
before follow_page/etc.
OTOH, if the file was opened without FMODE_WRITE, then I do not
really understand how (PROT_READ, MAP_SHARED) differs from
(PROT_READ, MAP_PRIVATE). However, in the latter case FOLL_FORCE
works, VM_MAYWRITE was not cleared.
Speaking of the difference above, I'd wish I could understand
what VM_MAYSHARE actually means except "MAP_SHARED was used".
Oleg.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roland Dreier <roland@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH RFC] mm: account VMA before forced-COW via /proc/pid/mem
Date: Sat, 7 Apr 2012 19:33:18 +0200 [thread overview]
Message-ID: <20120407173318.GA5076@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1204062104090.4297@eggly.anvils>
On 04/06, Hugh Dickins wrote:
>
> I've long detested that behaviour of GUP write,force, and my strong
> preference would be not to layer more strangeness upon strangeness,
> but limit the damage by making GUP write,force fail in that case,
> instead of inserting a PageAnon page into a VM_SHARED mapping.
>
> I think it's unlikely that it will cause a regression in real life
> (it already fails if you did not open the mmap'ed file for writing),
Yes, and this is what looks confusing to me. Assuming I understand
you (and the code) correctly ;)
If we have a (PROT_READ, MAP_SHARED) file mapping, then FOLL_FORCE
works depending on "file->f_mode & FMODE_WRITE".
Afaics, because do_mmap_pgoff(MAP_SHARED) clears VM_MAYWRITE if
!FMODE_WRITE, and gup(FORCE) checks "vma->vm_flags & VM_MAYWRITE"
before follow_page/etc.
OTOH, if the file was opened without FMODE_WRITE, then I do not
really understand how (PROT_READ, MAP_SHARED) differs from
(PROT_READ, MAP_PRIVATE). However, in the latter case FOLL_FORCE
works, VM_MAYWRITE was not cleared.
Speaking of the difference above, I'd wish I could understand
what VM_MAYSHARE actually means except "MAP_SHARED was used".
Oleg.
next prev parent reply other threads:[~2012-04-07 17:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 15:36 [PATCH RFC] mm: account VMA before forced-COW via /proc/pid/mem Konstantin Khlebnikov
2012-04-02 15:36 ` Konstantin Khlebnikov
2012-04-03 14:37 ` Oleg Nesterov
2012-04-03 14:37 ` Oleg Nesterov
2012-04-04 9:59 ` Konstantin Khlebnikov
2012-04-04 9:59 ` Konstantin Khlebnikov
2012-04-04 15:41 ` Oleg Nesterov
2012-04-04 15:41 ` Oleg Nesterov
2012-04-05 8:31 ` Konstantin Khlebnikov
2012-04-05 8:31 ` Konstantin Khlebnikov
2012-04-07 4:21 ` Hugh Dickins
2012-04-07 4:21 ` Hugh Dickins
2012-04-07 5:11 ` Konstantin Khlebnikov
2012-04-07 5:11 ` Konstantin Khlebnikov
2012-04-10 0:34 ` Hugh Dickins
2012-04-10 0:34 ` Hugh Dickins
2012-04-07 17:33 ` Oleg Nesterov [this message]
2012-04-07 17:33 ` Oleg Nesterov
2012-04-10 1:04 ` Hugh Dickins
2012-04-10 1:04 ` Hugh Dickins
2012-04-10 1:35 ` Oleg Nesterov
2012-04-10 1:35 ` Oleg Nesterov
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=20120407173318.GA5076@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=khlebnikov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=roland@kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.