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? -hpa -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>