On 10/07/2019 07:12, Thomas Gleixner wrote: > On Tue, 9 Jul 2019, John Stultz wrote: >> Though unfortunately, it seems the arm64 vdso code that just landed is >> breaking AOSP for me. >> >> I see a lot of the following errors: >> 01-01 01:22:14.097 755 755 F libc : Fatal signal 11 (SIGSEGV), >> code 1 (SEGV_MAPERR), fault addr 0x3cf2c96c in tid 755 (cameraserver), >> pid 755 (cameraserver) >> 01-01 01:22:14.112 759 759 F libc : Fatal signal 11 (SIGSEGV), >> code 1 (SEGV_MAPERR), fault addr 0x3cf2c96c in tid 759 >> (android.hardwar), pid 759 (android.hardwar) >> 01-01 01:22:14.120 756 756 F libc : Fatal signal 11 (SIGSEGV), >> code 1 (SEGV_MAPERR), fault addr 0x3cf2c96c in tid 756 (drmserver), >> pid 756 (drmserver) >> >> Which go away if I revert the vdso merge that went in via tip/timers. >> >> I tried to bisect things down a bit, but as some later fixes are >> required (at one point, date was returning the start epoch and never >> increasing), this hasn't worked too well. But I'm guessing since I >> see: "CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will >> not be built", and the system is half working, I'm guessing this is an >> issue with just the 32bit code failing. While I can try to sort out >> the proper CROSS_COMPILE_COMPAT in my build environment, I assume >> userland shouldn't be crashing if that value isn't set. > > The obvious question is whether the VDSO is mapped to the 32bit process in > that case. It shouldn't... > Agreed. I am investing if/why this is happening and will post a fix accordingly. > Thanks, > > tglx > -- Regards, Vincenzo
