From: Andy Lutomirski <luto@amacapital.net>
To: Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
X86 ML <x86@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [RFC 0/6] mm, x86: New special mapping ops
Date: Wed, 29 Oct 2014 17:57:19 -0700 [thread overview]
Message-ID: <CALCETrWfRMyMkReQmtbmK75jyAKDCGn7tWeqh2UBsuSKFAA+sQ@mail.gmail.com> (raw)
In-Reply-To: <cover.1414629045.git.luto@amacapital.net>
On Wed, Oct 29, 2014 at 5:42 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> This is an attempt to make the core special mapping infrastructure
> track what arch vdso code needs better than it currently does. It
> adds:
>
> .start_addr_set: A callback to notify arch code that a special mapping
> was mremapped. (CRIU does this. Without something like this, it's
> somewhat broken for 64-bit userspace and completely broken for 32-bit
> userspace on Intel hardware. Apparently no one has noticed the 64-bit
> breakage, and no one ever ported CRIU to 32-bit in the first place.)
>
> .fault: Directly fault handling on the vdso. Imagine that! It turns
> out that storing a list of struct page pointers in the special mapping
> data is awkward for pretty much everyone and completely precludes
> mapping things that aren't pages without dirty hacks. (x86 uses dirty
> hacks for the HPET mapping. See below.)
I should add that there's further motivation for this. I want to change the x86
vdso code so that the HPET is only mapped if it's actually in use. Getting
this right is delicate, but it's almost impossible without this change.
In particular, if the HPET gets selected due to TSC instability after
boot, then there's no good way to start allowing access right now.
I'd have to remap_pfn_range on all mms at (egads!) an unknown address,
whereas now I can just start accepting the reference in .fault.
Getting the other direction right is tricky, but it's doable in a
number of ways.
--Andy
--
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>
prev parent reply other threads:[~2014-10-30 0:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 0:42 Andy Lutomirski
2014-10-30 0:42 ` [RFC 1/6] mm: Add a mechanism to track the current address of a special mapping Andy Lutomirski
2014-10-30 0:42 ` [RFC 2/6] x86,vdso: Use special mapping tracking for the vdso Andy Lutomirski
2014-10-30 0:42 ` [RFC 3/6] mm: Add a vm_special_mapping .fault method Andy Lutomirski
2014-10-30 0:42 ` [RFC 4/6] mm: Add vm_insert_pfn_prot Andy Lutomirski
2014-10-30 0:42 ` [RFC 5/6] x86,vdso: Use .fault instead of remap_pfn_range for the vvar mapping Andy Lutomirski
2014-10-30 0:42 ` [RFC 6/6] x86,vdso: Use .fault for the vdso text mapping Andy Lutomirski
2014-10-30 0:57 ` Andy Lutomirski [this message]
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=CALCETrWfRMyMkReQmtbmK75jyAKDCGn7tWeqh2UBsuSKFAA+sQ@mail.gmail.com \
--to=luto@amacapital.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox