Hello, Sorry for being so late.
On Thu, Dec 27, 2018 at 05:35:17PM -0800, Florian Fainelli wrote: > Le 12/27/18 à 2:55 AM, Namhyung Kim a écrit : > > Hello, > > > > On Thu, Dec 20, 2018 at 07:43:35PM -0800, Florian Fainelli wrote: > >> Hi all, > >> > >> I just painfully learned that perf would segfault when > >> CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of > > > > Could you please elaborate? > > Sure, I was debugging why perf was segfaulting on my systems and saw > that the faulting address was within 0xffff_0000 (high vectors); and > because CONFIG_KUSER_HELPERS was not enabled, nothing was mapped at that > address so this was a legitimate crash. This was on a variety of ARMv7A > systems, Cortex-A9, Cortex-A5 etc. > > Later on, I found that in tools/arch/arm/include/asm/barrier.h the > barriers are unconditionally defined to make use of the [vectors] page > that the ARM kernel only sets up when CONFIG_KUSER_HELPERS is enabled > and this is the reason for the crash. > > Testing for the page itself is pretty harmless if you think we should > make something more robust around checking for HAVE_AUXTRACE_SUPPORT > (which appears to be the specific location making use of barriers), let > me know. Thanks for the explanation. Is there anything we can do instead if CONFIG_KUSER_HELPERS is not defined? I think it'd be better making the barriers into functions (probably with "static inline") and configurable depending on a result of runtime checking of the availability (like you did). The init routine of the auxtrace (or other future users of barriers) should call an arch-specific function to check the availability then. Thanks, Namhyung