All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: 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>
Subject: Re: vvar, gup && coredump
Date: Thu, 12 Mar 2015 17:54:23 +0100	[thread overview]
Message-ID: <20150312165423.GA10073@redhat.com> (raw)
In-Reply-To: <CALCETrW5rmAHutzm_OwK2LTd_J0XByV3pvWGyW=AmC=v7rLfhQ@mail.gmail.com>

On 03/12, Andy Lutomirski wrote:
>
> On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > What is not clear: do we really want gup() to fail? Or it is not trivial
> > to turn __vvar_page into the "normal" page? (to simplify the discussion,
> > lets ignore hpet mapping for now).
>
> We could presumably fiddle with the vma to allow get_user_pages to
> work on at least the first vvar page.  There are some decently large
> caveats, though:
>
>  - We don't want to COW it.  If someone pokes at that page with
> ptrace, for example, and it gets COWed, everything will stop working
> because the offending process will no longer see updates.  That way
> lies infinite loops.

Of course, but this looks simple... is_cow_mapping() == F so FOLL_FORCE
won't work anyway?

>  - The implementation could be odd.  The vma is either VM_MIXEDMAP or
> VM_PFNMAP, and I don't see any practical way to change that.
>
>  - The HPET and perhaps pvclock stuff.  The HPET probably doesn't have
> a struct page at all, so you can't possibly get_user_pages it.

Yes, this is true. OK, lets not dump it. I'll probably send a patch which
changes vma_dump_size() to check VM_DONTDUMP first...

But this leads to another question: why do we want to expose this
"vvar" vma at all?

For the moment, forget about compat 32-bit applications running under
64-bit kernel.

Can't we simply add FIX_VVAR_PAGE into fixed_addresses{}, map it into
init_mm via set_fixmap(FIX_VVAR_PAGE, __PAGE_USER) and change __vdso.*
functions to use fix_to_virt() address?

I don't really understand the low-level details, I'd like to understand
if this can work or not. And if it can work, why this is undesirable.

As for 32-bit applications. Yes, this can't work because 32-bit simply
can't access this "high" memory. But you know, it would be very nice to
have the fixmap-like "global" area in init_mm which is also visible to
compat applications. If we had it, uprobes could work without xol vma's.

Oleg.


  reply	other threads:[~2015-03-12 16:56 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 [this message]
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
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=20150312165423.GA10073@redhat.com \
    --to=oleg@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=palves@redhat.com \
    --cc=sergiodj@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 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.