Re: [PATCH v3 0/2] perf tests: Check for ARM [vectors] page

[Namhyung Kim <namhyung@kernel.org>]

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