[PATCH 1/1] cr: remap vdso at original address
Serge E. Hallyn
serue at us.ibm.com
Mon Mar 30 15:58:44 PDT 2009
Quoting Oren Laadan (orenl at cs.columbia.edu):
> Actually, I think that the get_gate_vma() is broken with randomized vdso
> in the main kernel - it simply won't work just like remapping won't work :)
> It simply didn't show up so far either because no-one is using it, or the
> function is not really important ?
I'm not so sure. It appears to be just an optimization for the
compat vdso mode. Well, so long as VDSO_HIGH_BASE isn't a
legitimate address for a user mapping when not in compat vdso
mode, which seems reasonable (0xffffe000U)?
So if not in compat vdso mode, then you don't use gate_vma, but notice
that powerpc for instance always returns 0 for in_gate_area() and NULL
> Who would be the right person to report this issue ?
Well git-blame suggests that the main people touching that code
have been Ingo and Jeremy.
> > 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?
> I fear that if we require that, then we forget to un-require it later ...
Nonsense, if people care about it they'll yell.
> Another thing that we should do it transder the vdso page (one copy of
> each page) from the checkpoint and compare to the version available at
> the restart. Yell if differs.
As Matt points out, we'd need an arch-specific comparison function which
ignores the data page.
> (vdso page pointer will be treated as a shared resource - so only copied
That seems beneficial at least.
More information about the Containers