[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1907100811170.1758@nanos.tec.linutronix.de>
Date: Wed, 10 Jul 2019 08:12:21 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <john.stultz@...aro.org>
cc: Vincenzo Frascino <vincenzo.frascino@....com>,
linux-arch@...r.kernel.org,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
lkml <linux-kernel@...r.kernel.org>, linux-mips@...r.kernel.org,
linux-kselftest@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
Andre Przywara <andre.przywara@....com>,
Arnd Bergmann <arnd@...db.de>,
Huw Davies <huw@...eweavers.com>,
Catalin Marinas <catalin.marinas@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Will Deacon <will.deacon@....com>,
Russell King <linux@...linux.org.uk>,
Ralf Baechle <ralf@...ux-mips.org>,
Mark Salyzyn <salyzyn@...roid.com>,
Paul Burton <paul.burton@...s.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Shijith Thotton <sthotton@...vell.com>,
Peter Collingbourne <pcc@...gle.com>
Subject: Re: [PATCH v7 10/25] arm64: compat: Add vDSO
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...
Thanks,
tglx
Powered by blists - more mailing lists