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: Wed, 18 Mar 2015 19:06:49 +0100 [thread overview]
Message-ID: <20150318180649.GA853@redhat.com> (raw)
In-Reply-To: <CALCETrVgzCrb6yfb3=MhBDXxtQgRNbsijBER502+Z2rOVKvipQ@mail.gmail.com>
On 03/17, Andy Lutomirski wrote:
>
> On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > 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...
>
> That's slightly tricky, I think, because it could start showing up in
> /proc/PID/map_files or whatever it's called, and I don't think we want
> that.
Hmm. To me this looke liks improvement. And again, with this change
uprobe-in-vdso can work.
OK, this is off-topic right now, lets forget this for the moment.
> Your patch does look like a considerable improvement, though. Let me
> see if I can find some time to fold it in with the rest of my special
> mapping rework over the next few days.
I'll try to recheck... Perhaps I'll send this (changed) patch for review.
This is a bugfix, even if the bug is minor.
And note that with this change vvar->access() becomes trivial. I think it
makes sense to fix "gup() fails in vvar" too. Gdb developers have enough
other problems with the poor kernel interfaces ;)
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/ .
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: Wed, 18 Mar 2015 19:06:49 +0100 [thread overview]
Message-ID: <20150318180649.GA853@redhat.com> (raw)
In-Reply-To: <CALCETrVgzCrb6yfb3=MhBDXxtQgRNbsijBER502+Z2rOVKvipQ@mail.gmail.com>
On 03/17, Andy Lutomirski wrote:
>
> On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > 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...
>
> That's slightly tricky, I think, because it could start showing up in
> /proc/PID/map_files or whatever it's called, and I don't think we want
> that.
Hmm. To me this looke liks improvement. And again, with this change
uprobe-in-vdso can work.
OK, this is off-topic right now, lets forget this for the moment.
> Your patch does look like a considerable improvement, though. Let me
> see if I can find some time to fold it in with the rest of my special
> mapping rework over the next few days.
I'll try to recheck... Perhaps I'll send this (changed) patch for review.
This is a bugfix, even if the bug is minor.
And note that with this change vvar->access() becomes trivial. I think it
makes sense to fix "gup() fails in vvar" too. Gdb developers have enough
other problems with the poor kernel interfaces ;)
Oleg.
next prev parent reply other threads:[~2015-03-18 18:51 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
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 [this message]
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=20150318180649.GA853@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.