linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-kernel@vger.kernel.org, cphealy@gmail.com,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Kim Phillips <kim.phillips@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ravi Bangoria <ravi.bangoria@linux.ibm.com>,
	Thomas Richter <tmricht@linux.ibm.com>,
	rmk+kernel@armlinux.org.uk, l.stach@pengutronix.de,
	kernel-team@lge.com
Subject: Re: [PATCH v3 0/2] perf tests: Check for ARM [vectors] page
Date: Thu, 27 Dec 2018 17:35:17 -0800	[thread overview]
Message-ID: <27ac27b2-c373-2831-e7ce-4e898365d517@gmail.com> (raw)
In-Reply-To: <20181227105539.GA4521@sejong>

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!

> 
> Thanks,
> Namhyung
> 
> 
>> it. This patch series adds an ARM test for that by leveraging the
>> existing find_vdso_map() function and making it more generic and capable
>> of location any map within /proc/self/maps.
>>
>> Changes in v3:
>>
>> - remove find_vdso_map() call find_map() with VDSO__MAP_NAME
>>
>> Changes in v2:
>>
>> - use strlen() instead of sizeof() -1 since we made the page name a
>>   parameter
>> - use TEST_OK/TEST_FAIL in lieu of 0/-1
>> - added an error message indicating CONFIG_KUSER_HELPERS might be
>>   disabled
>>
>> Florian Fainelli (2):
>>   perf tools: Make find_vdso_map() more modular
>>   perf tests: Add a test for the ARM 32-bit [vectors] page
>>
>>  tools/perf/Makefile.perf                      |  4 ++--
>>  tools/perf/arch/arm/tests/Build               |  1 +
>>  tools/perf/arch/arm/tests/arch-tests.c        |  4 ++++
>>  tools/perf/arch/arm/tests/vectors-page.c      | 24 +++++++++++++++++++
>>  tools/perf/perf-read-vdso.c                   |  6 ++---
>>  tools/perf/tests/tests.h                      |  5 ++++
>>  .../perf/util/{find-vdso-map.c => find-map.c} |  7 +++---
>>  tools/perf/util/vdso.c                        |  6 ++---
>>  8 files changed, 45 insertions(+), 12 deletions(-)
>>  create mode 100644 tools/perf/arch/arm/tests/vectors-page.c
>>  rename tools/perf/util/{find-vdso-map.c => find-map.c} (71%)
>>
>> -- 
>> 2.17.1
>>


-- 
Florian

  reply	other threads:[~2018-12-28  1:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21  3:43 [PATCH v3 0/2] perf tests: Check for ARM [vectors] page Florian Fainelli
2018-12-21  3:43 ` [PATCH v3 1/2] perf tools: Make find_vdso_map() more modular Florian Fainelli
2019-01-09  7:11   ` [tip:perf/urgent] " tip-bot for Florian Fainelli
2018-12-21  3:43 ` [PATCH v3 2/2] perf tests: Add a test for the ARM 32-bit [vectors] page Florian Fainelli
2019-01-09  7:11   ` [tip:perf/urgent] " tip-bot for Florian Fainelli
2018-12-27 10:55 ` [PATCH v3 0/2] perf tests: Check for ARM " Namhyung Kim
2018-12-28  1:35   ` Florian Fainelli [this message]
2019-01-11  2:11     ` Namhyung Kim
2019-01-01 17:39 ` Jiri Olsa
2019-01-08 13:23   ` Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27ac27b2-c373-2831-e7ce-4e898365d517@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=cphealy@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jolsa@redhat.com \
    --cc=kernel-team@lge.com \
    --cc=kim.phillips@arm.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=tglx@linutronix.de \
    --cc=tmricht@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).