From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH 1/1] cr: remap vdso at original address
Date: Mon, 30 Mar 2009 09:50:54 -0500 [thread overview]
Message-ID: <20090330145054.GA23411@us.ibm.com> (raw)
In-Reply-To: <49D0C977.8060807-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>
>
> Serge E. Hallyn wrote:
> > Well, here is my current attempt at properly handling vdso for
> > the x86 and s390 c/r code. I was going to test with gettimeofday,
> > but x86 doesn't use vdso for that, and I'm still recompiling glibc
> > on s390 to exploit vdso for it. So what I can tell so far is that
> > CONFIG_COMPAT_VDSO=n is now save on x86 - the kernel vdso segment
> > is re-mapped from the kernel into the checkpointed location, so
> > the fact that the task was started with a random vdso base doesn't
> > matter.
> >
> > Once I get a proper testcase, I intend to show that checkpointing
> > a testcase which does gettimeofday(), waiting 10 seconds, and
> > then restarting it, will end up with bad __vdso_gettimeofday()
> > results without this patch, and good ones with it.
>
> It will be helpful if you split the patch into non-c/r changes (i.e.
> add a parameter to request mapping for vdso), following by c/r changes
> per architecture.
Actually, since sending this patch I've been trying to exercise the
vdso on 4 different systems (s390, x86, powerpc). Only on powerpc
was i able to confirm vdso was being used, and there not having this
patch made zero difference.
So right now I'm thinking the only thing that is needed is to either
demand COMPAT_VDSO=y on x86, or to take the part of this patch where
we reset context.vdso.
> Also, I noticed that it may be more complicated. For example, the
> function get_gate_vma() (at least on x86) test the value of context.vdso
> against some constant to decide on the return value. I don't know if
> this will break if the vdso of a task ends up being something that the
> system didn't expect it to be ?
Yeah that logic will need a tweak, thanks.
But so for now I'm definately withdrawing this patch. In the meantime,
do we prefer requiring COMPAT_VDSO (using config logic?), or do we
prefer resetting the context.vdso on x86 at restart?
thanks,
-serge
next prev parent reply other threads:[~2009-03-30 14:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-25 14:31 [PATCH 1/1] cr: remap vdso at original address Serge E. Hallyn
[not found] ` <20090325143116.GA14040-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-30 13:30 ` Oren Laadan
[not found] ` <49D0C977.8060807-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-03-30 14:50 ` Serge E. Hallyn [this message]
[not found] ` <20090330145054.GA23411-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-30 15:02 ` Oren Laadan
[not found] ` <49D0DF07.7030604-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-03-30 19:26 ` Matt Helsley
[not found] ` <20090330192631.GA29821-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-30 22:55 ` Oren Laadan
2009-03-30 22:58 ` Serge E. Hallyn
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=20090330145054.GA23411@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.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.