[lkml]   [2019]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 0/2] perf tests: Check for ARM [vectors] page

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

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.


 \ /
  Last update: 2019-01-11 03:11    [W:0.059 / U:1.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site