On 04/29/2016 04:22 PM, Christopher Covington wrote:
On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
Also, at some point, possibly quite soon, x86 will want a way for
user code to ask the kernel to map a specific vdso variant at a specific
address. Could we perhaps add a new pair of syscalls:
struct vdso_info {
unsigned long space_needed_before;
unsigned long space_needed_after;
unsigned long alignment;
};
long vdso_get_info(unsigned int vdso_type, struct vdso_info *info);
long vdso_remap(unsigned int vdso_type, unsigned long addr, unsigned int flags);
#define VDSO_X86_I386 0
#define VDSO_X86_64 1
#define VDSO_X86_X32 2
// etc.
vdso_remap will map the vdso of the chosen type such at
AT_SYSINFO_EHDR lines up with addr. It will use up to
space_needed_before bytes before that address and space_needed_after
after than address. It will also unmap the old vdso (or maybe only do
that if some flag is set).
On x86, mremap is *not* sufficient for everything that's needed,
because some programs will need to change the vdso type.
I don't I understand. Why can't people just exec() the ELF type that
corresponds to the VDSO they want?
I may say about my needs in it: to not lose all the existing
information in application.
Imagine you're restoring a container with 64-bit and 32-bit
applications (in compatible mode). So you need somehow
switch vdso type in restorer for a 32-bit application.
Yes, you may exec() and then - all already restored application
properties will got lost. You will need to transpher information
about mappings, make protocol between restorer binary
and main criu application, finally you'll end up with some
really much more difficult architecture than it is now.
And it'll be slower.
Also it's pretty logical: if one can switch between modes,
why can't he change vdso mapping to mode he got to?
(note: if the work about removing thread compatible flags
will be done (on x86), there will not even be such a thing,
as application mode - just difference on which syscalls it
uses: compatible or native).
Thanks,
Dmitry Safonov
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
