On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold <stef...@seibold.net> wrote: > > Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski: >> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold <stef...@seibold.net> wrote: >> > Hi Fengguang, >> > >> > i have build a kernel with the config, but my kvm is unable to start it. >> > I will try to find a way to test your kernek config. >> > >> > One thing is the crash point: >> > >> > The function sysenter_setup was modified by Andy, maybe he has an idea >> > what fails. >> >> *sigh* >> >> My host kernel is currently fscked up and won't run KVM. Also, I want >> to confirm that I'm reproducing exactly what you're seeing, and I >> think it depends on the toolchain. Can you (Fenguang) do: >> >> $ ls -l arch/x86/vdso/vdso32*.so >> -rwxrwxr-x. 1 luto luto 4096 Mar 7 10:19 arch/x86/vdso/vdso32-int80.so >> -rwxrwxr-x. 1 luto luto 4116 Mar 7 10:19 arch/x86/vdso/vdso32-sysenter.so >> >> (Of course, triggering this depends on which image gets selected.) >> > > Yes, that what i also figured out. There are two culprits: > CONFIG_OPTIMIZE_INLINING and CONFIG_X86_PPRO_FENCE. Each of them > increase the size of the code by about 500 bytes. > > When i add to file arch/x86/vdso/vdso32/vclock_gettime.c > > #undef CONFIG_OPTIMIZE_INLINING > #undef CONFIG_X86_PPRO_FENCE > > this will solve the issue. > >> Note that we have a .so file that exceeds 4k, i.e. one page. Then >> read the relevant code and wonder what everyone was smoking when they >> wrote it. There are so many buffer overflows, screwed up >> initializations, unnecessary and incorrect copies, etc, that I don't >> even want to speculate on what the first failure will be when the >> image is bigger than a page. >> > > Right. So the above one will not really solve it. At least when > __vdso_getcpu() code will also become a part of the 32 bit VDSO. > >> It's easy enough to fix, but someone should figure out what the impact >> will be on the compat vdso case. >> >> I wonder how hard it would be to change the compat vdso do be a dummy >> image a la the x86_64 fake vsyscall page so that old code can keep >> working (maybe with a performance hit) and new code can use a sane >> image. >> > > That is exactly what i wrote one week ago: > > Move the VDSO code before the VDSO compat fixmap area and create a kind > of helper VDSO for the VDSO compat fixmap page, which only calls the > real VDSO. But this would result in a performance regression for the > VDSO compat mode.
I think that regressing performance for compat_vdso (only) users is fine. We need to figure out what those users are. I have a vague recollection that it's a particular version of SuSE or OpenSuSE. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
