On May 16, 2014 4:56 PM, "H. Peter Anvin" <hpa@xxxxxxxxx> wrote:
>
> On 05/16/2014 03:40 PM, Andy Lutomirski wrote:
> >
> > My current draft is here:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups
> >
> > On 64-bit userspace, it results in:
> >
> > 7fffa1dfd000-7fffa1dfe000 r-xp 00000000 00:00 0 [vdso]
> > 7fffa1dfe000-7fffa1e00000 r--p 00000000 00:00 0 [vvar]
> > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
> > [vsyscall]
> >
> > On 32-bit userspace, it results in:
> >
> > f7748000-f7749000 r-xp 00000000 00:00 0 [vdso]
> > f7749000-f774b000 r--p 00000000 00:00 0 [vvar]
> > ffd94000-ffdb5000 rw-p 00000000 00:00 0 [stack]
> >
> > Is this good for CRIU? Another approach would be to name both of
> > these things "vdso", since they are sort of both the vdso, but that
> > might be a bit confusing -- [vvar] is not static text the way that
> > [vdso] is.
> >
> > If I backport this for 3.15 (which might be nasty -- I would argue
> > that the code change is actually a cleanup, but it's fairly
> > intrusive), then [vvar] will be *before* [vdso], not after it. I'd be
> > very hesitant to name both of them "[vdso]" in that case, since there
> > is probably code that assumes that the beginning of "[vdso]" is a DSO.
> >
> > Note that it is *not* safe to blindly read from "[vvar]". On some
> > configurations you *will* get SIGBUS if you try to read from some of
> > the vvar pages. (That's what started this whole thread.) Some pages
> > in "[vvar]" may have strange caching modes, so SIGBUS might not be the
> > only surprising thing about poking at it.
> >
>
> mremap() should work on these pages, right?
(On phone, so this may bounce)
Does mremap work with remap_pfn_range? We can't handle faults on the vvar mapping.
I haven't tested at all, but it looks like arch_vma_name may get rather confused if mremap happens. Also, 32-bit code will crash and burn if the vdso moves -- sysexit and sigreturn will die horrible deaths, I think. None of these issues are new to 3.15.
--Andy
>
> -hpa
>
>