From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Hugh Dickins <hughd@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
Sergio Durigan Junior <sergiodj@redhat.com>,
GDB Patches <gdb-patches@sourceware.org>,
Pedro Alves <palves@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: install_special_mapping && vm_pgoff (Was: vvar, gup && coredump)
Date: Tue, 17 Mar 2015 14:43:09 +0100 [thread overview]
Message-ID: <20150317134309.GA365@redhat.com> (raw)
In-Reply-To: <20150316194446.GA21791@redhat.com>
On 03/16, Oleg Nesterov wrote:
>
> On 03/16, Andy Lutomirski wrote:
> >
> > Ick, you're probably right. For what it's worth, the vdso *seems* to
> > be okay (on 64-bit only, and only if you don't poke at it too hard) if
> > you mremap it in one piece. CRIU does that.
>
> I need to run away till tomorrow, but looking at this code even if "one piece"
> case doesn't look right if it was cow'ed. I'll verify tomorrow.
And I am still not sure this all is 100% correct, but I got lost in this code.
Probably this is fine...
But at least the bug exposed by the test-case looks clear:
do_linear_fault:
vmf->pgoff = (((address & PAGE_MASK) - vma->vm_start) >> PAGE_SHIFT)
+ vma->vm_pgoff;
...
special_mapping_fault:
pgoff = vmf->pgoff - vma->vm_pgoff;
So special_mapping_fault() can only work if this mapping starts from the
first page in ->pages[].
So perhaps we need _something like_ the (wrong/incomplete) patch below...
Or, really, perhaps we can create vdso_mapping ? So that map_vdso() could
simply mmap the anon_inode file...
Oleg.
--- x/mm/mmap.c
+++ x/mm/mmap.c
@@ -2832,6 +2832,8 @@ int insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma)
return 0;
}
+bool is_special_vma(struct vm_area_struct *vma);
+
/*
* Copy the vma structure to a new location in the same mm,
* prior to moving page table entries, to effect an mremap move.
@@ -2851,7 +2853,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
* If anonymous vma has not yet been faulted, update new pgoff
* to match new location, to increase its chance of merging.
*/
- if (unlikely(!vma->vm_file && !vma->anon_vma)) {
+ if (unlikely(!vma->vm_file && !is_special_vma(vma) && !vma->anon_vma)) {
pgoff = addr >> PAGE_SHIFT;
faulted_in_anon_vma = false;
}
@@ -2953,6 +2955,11 @@ static const struct vm_operations_struct legacy_special_mapping_vmops = {
.fault = special_mapping_fault,
};
+bool is_special_vma(struct vm_area_struct *vma)
+{
+ return vma->vm_ops == &special_mapping_vmops;
+}
+
static int special_mapping_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
{
@@ -2965,7 +2972,7 @@ static int special_mapping_fault(struct vm_area_struct *vma,
* We are allowed to do this because we are the mm; do not copy
* this code into drivers!
*/
- pgoff = vmf->pgoff - vma->vm_pgoff;
+ pgoff = vmf->pgoff;
if (vma->vm_ops == &legacy_special_mapping_vmops)
pages = vma->vm_private_data;
@@ -3014,6 +3021,7 @@ static struct vm_area_struct *__install_special_mapping(
if (ret)
goto out;
+ vma->vm_pgoff = 0;
mm->total_vm += len >> PAGE_SHIFT;
perf_event_mmap(vma);
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Hugh Dickins <hughd@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
Sergio Durigan Junior <sergiodj@redhat.com>,
GDB Patches <gdb-patches@sourceware.org>,
Pedro Alves <palves@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: install_special_mapping && vm_pgoff (Was: vvar, gup && coredump)
Date: Tue, 17 Mar 2015 14:43:09 +0100 [thread overview]
Message-ID: <20150317134309.GA365@redhat.com> (raw)
In-Reply-To: <20150316194446.GA21791@redhat.com>
On 03/16, Oleg Nesterov wrote:
>
> On 03/16, Andy Lutomirski wrote:
> >
> > Ick, you're probably right. For what it's worth, the vdso *seems* to
> > be okay (on 64-bit only, and only if you don't poke at it too hard) if
> > you mremap it in one piece. CRIU does that.
>
> I need to run away till tomorrow, but looking at this code even if "one piece"
> case doesn't look right if it was cow'ed. I'll verify tomorrow.
And I am still not sure this all is 100% correct, but I got lost in this code.
Probably this is fine...
But at least the bug exposed by the test-case looks clear:
do_linear_fault:
vmf->pgoff = (((address & PAGE_MASK) - vma->vm_start) >> PAGE_SHIFT)
+ vma->vm_pgoff;
...
special_mapping_fault:
pgoff = vmf->pgoff - vma->vm_pgoff;
So special_mapping_fault() can only work if this mapping starts from the
first page in ->pages[].
So perhaps we need _something like_ the (wrong/incomplete) patch below...
Or, really, perhaps we can create vdso_mapping ? So that map_vdso() could
simply mmap the anon_inode file...
Oleg.
--- x/mm/mmap.c
+++ x/mm/mmap.c
@@ -2832,6 +2832,8 @@ int insert_vm_struct(struct mm_struct *mm, struct vm_area_struct *vma)
return 0;
}
+bool is_special_vma(struct vm_area_struct *vma);
+
/*
* Copy the vma structure to a new location in the same mm,
* prior to moving page table entries, to effect an mremap move.
@@ -2851,7 +2853,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
* If anonymous vma has not yet been faulted, update new pgoff
* to match new location, to increase its chance of merging.
*/
- if (unlikely(!vma->vm_file && !vma->anon_vma)) {
+ if (unlikely(!vma->vm_file && !is_special_vma(vma) && !vma->anon_vma)) {
pgoff = addr >> PAGE_SHIFT;
faulted_in_anon_vma = false;
}
@@ -2953,6 +2955,11 @@ static const struct vm_operations_struct legacy_special_mapping_vmops = {
.fault = special_mapping_fault,
};
+bool is_special_vma(struct vm_area_struct *vma)
+{
+ return vma->vm_ops == &special_mapping_vmops;
+}
+
static int special_mapping_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
{
@@ -2965,7 +2972,7 @@ static int special_mapping_fault(struct vm_area_struct *vma,
* We are allowed to do this because we are the mm; do not copy
* this code into drivers!
*/
- pgoff = vmf->pgoff - vma->vm_pgoff;
+ pgoff = vmf->pgoff;
if (vma->vm_ops == &legacy_special_mapping_vmops)
pages = vma->vm_private_data;
@@ -3014,6 +3021,7 @@ static struct vm_area_struct *__install_special_mapping(
if (ret)
goto out;
+ vma->vm_pgoff = 0;
mm->total_vm += len >> PAGE_SHIFT;
perf_event_mmap(vma);
next prev parent reply other threads:[~2015-03-17 13:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <878ufc9kau.fsf@redhat.com>
[not found] ` <20150305154827.GA9441@host1.jankratochvil.net>
[not found] ` <87zj7r5fpz.fsf@redhat.com>
[not found] ` <20150305205744.GA13165@host1.jankratochvil.net>
[not found] ` <20150311200052.GA22654@redhat.com>
2015-03-12 14:34 ` vvar, gup && coredump Oleg Nesterov
2015-03-12 16:29 ` Andy Lutomirski
2015-03-12 16:54 ` Oleg Nesterov
2015-03-12 17:17 ` Andy Lutomirski
2015-03-12 17:39 ` Oleg Nesterov
2015-03-12 17:45 ` Sergio Durigan Junior
2015-03-12 18:02 ` Oleg Nesterov
2015-03-13 4:50 ` Sergio Durigan Junior
2015-03-13 15:04 ` Oleg Nesterov
2015-03-12 17:55 ` Andy Lutomirski
2015-03-12 18:08 ` Oleg Nesterov
2015-03-12 18:33 ` Andy Lutomirski
2015-03-13 15:22 ` Oleg Nesterov
2015-03-12 17:46 ` Oleg Nesterov
2015-03-12 17:54 ` Andy Lutomirski
2015-03-12 18:05 ` Oleg Nesterov
2015-03-12 18:23 ` Sergio Durigan Junior
2015-03-12 18:19 ` Pedro Alves
2015-03-12 18:25 ` Andy Lutomirski
2015-03-16 19:01 ` install_special_mapping && vm_pgoff (Was: vvar, gup && coredump) Oleg Nesterov
2015-03-16 19:20 ` Andy Lutomirski
2015-03-16 19:20 ` Andy Lutomirski
2015-03-16 19:44 ` Oleg Nesterov
2015-03-16 19:44 ` Oleg Nesterov
2015-03-17 13:43 ` Oleg Nesterov [this message]
2015-03-17 13:43 ` Oleg Nesterov
2015-03-18 1:44 ` Andy Lutomirski
2015-03-18 1:44 ` Andy Lutomirski
2015-03-18 18:06 ` Oleg Nesterov
2015-03-18 18:06 ` Oleg Nesterov
2015-03-16 19:40 ` Pedro Alves
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=20150317134309.GA365@redhat.com \
--to=oleg@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=hughd@google.com \
--cc=jan.kratochvil@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=palves@redhat.com \
--cc=sergiodj@redhat.com \
--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.