From: Nathan_Lynch@mentor•com (Nathan Lynch)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v9 0/6] ARM: VDSO
Date: Wed, 3 Sep 2014 15:03:06 -0500 [thread overview]
Message-ID: <540773FA.5020108@mentor.com> (raw)
In-Reply-To: <CALCETrX7Q34nyU7YZfQYnYFPVSaquJ5WzO-AVPnW5PJUCNqopQ@mail.gmail.com>
On 09/03/2014 11:59 AM, Andy Lutomirski wrote:
> On Sep 2, 2014 10:44 PM, "Nathan Lynch" <Nathan_Lynch@mentor•com> wrote:
>>
>> On 08/27/2014 03:49 PM, Christopher Covington wrote:
>>>
>>> It appears to me that there is code in several architecture subdirectories
>>> (I'm aware of x86, arm64, and with these patches arm[32] and I would be
>>> surprised if there weren't more) doing largely the same setup of special
>>> mappings at randomized offsets, checking ELF magic etc. Not that these patches
>>> should necessarily do it, but is there a reasonable amount of consolidation
>>> that could be done, or am I underestimating how much of this really does vary
>>> per architecture?
>>
>> Sorry to not respond to this promptly, was distracted by some other work.
>>
>> As Andy said, the possibility for consolidating some aspects of VDSO support
>> is there, but it would be a fair bit of work.
>>
>> For example, arch_setup_additional_pages tends to have the general form of:
>>
>> lock mmap_sem
>> get_unmapped_area
>> install_special_mapping (or _install_special_mapping, preferably)
>> stash vdso address in mmu context
>> release mmap_sem
>>
>> But there are a lot of implementation details that differ:
>>
>> +----------------------------------------------------------------
>> | Number of VMAs installed
>> | +------------------------------------------------------------
>> | | Considers uses_interp
>> | | +------------------------------------------------------
>> | | | Uses _install_special_mapping
>> | | | +------------------------------------------------
>> | | | | Performs additional work (e.g. remap_pfn_range)
>> | | | | +------------------------------------------
>> | | | | | Randomizes VDSO offset vs stack and libs
>> | | | | | +------------------------------------
>> | | | | | | Records VDSO address in mmu context
>> | | | | | | +------------------------------
>> | | | | | | | Supports compat VDSO
>> | | | | | | | +------------------------
>> | | | | | | | | Supports disabling VDSO
>> | | | | | | | | at boot (e.g. vdso=off)
>> | | | | | | | | +------------------
>> | | | | | | | | | Can disable VDSO
>> arch | | | | | | | | | via Kconfig
>> ---------+---+-----+-----+-----+-----+-----+-----+-----+------------------
>> arm* | 3 | no | yes | no | yes | yes | no | no | yes
>> arm64 | 2 | no | yes | no | no | yes | no | no | no
>> hexagon | 1 | no | no | no | no | yes | no | no | no
>> mips | 1 | no | no | no | no | yes | no | no | no
>> powerpc | 1 | no | no | no | no | yes | yes | no | no
>> s390 | 1 | yes | no | no | no | yes | yes | yes | no
>> sh | 1 | no | no | no | no | yes | no | yes | yes
>> tile | 1 | no | no | yes | no | yes | no | yes | no
>> x86 | 2 | no | yes | yes | yes | yes | yes | yes | no
>>
>> * With VDSO patches from this thread, of course.
>>
>> I think pushing the mmap_sem lock/unlock up into the ELF loader might be
>> of some benefit (slightly reduced complexity in the arch code). But
>> any generic replacement for arch_setup_additional_pages will have to
>> account for all the differences above, and probably a few more I've
>> missed.
>>
>
> Wow, nice table! I think that we should eventually get rid of most of
> these differences.
Thanks, and agreed.
> Christopher, since you seem to be interested in CRIU, one thing to
> note is that any architecture that shoves a pointer to the vdso into
> the mmu context is likely to fail if the vdso is mremapped. CRIU
> needs to mremap the vdso, so this is a problem.
>
> x86_64 is an exception: it doesn't use that pointer for anything.
Hmm, I would expect architectures that implement arch_vma_name like so
to experience problems with CRIU:
const char *arch_vma_name(struct vm_area_struct *vma)
{
if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
return "[vdso]";
return NULL;
}
Is this what you're referring to?
Looking at 3.17-rc3, every arch uses mm_context_t->vdso_base or
similar to provide a value for AT_SYSINFO_EHDR at exec time.
Is this also problematic?
next prev parent reply other threads:[~2014-09-03 20:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 21:52 [PATCH v9 0/6] ARM: VDSO Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 1/6] ARM: use _install_special_mapping for sigpage Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 2/6] ARM: place sigpage at a random offset above stack Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 3/6] ARM: miscellaneous vdso infrastructure, preparation Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 4/6] ARM: add vdso user-space code Nathan Lynch
2014-09-10 16:47 ` Will Deacon
2014-09-10 16:52 ` Andy Lutomirski
2014-09-10 17:10 ` Will Deacon
2014-09-10 17:25 ` Nathan Lynch
2014-09-12 6:50 ` Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 5/6] ARM: vdso initialization, mapping, and synchronization Nathan Lynch
2014-08-22 21:52 ` [PATCH v9 6/6] ARM: add CONFIG_VDSO Kconfig and Makefile bits Nathan Lynch
2014-08-27 20:49 ` [PATCH v9 0/6] ARM: VDSO Christopher Covington
2014-08-27 21:42 ` Andy Lutomirski
2014-09-03 5:41 ` Nathan Lynch
2014-09-03 13:13 ` Christopher Covington
2014-09-03 16:59 ` Andy Lutomirski
2014-09-03 20:03 ` Nathan Lynch [this message]
2014-09-03 20:12 ` Andy Lutomirski
2014-09-06 2:32 ` Nathan Lynch
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=540773FA.5020108@mentor.com \
--to=nathan_lynch@mentor$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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