linux-kernel - Re: perf/jit doesn't cope well with mprotect() to jit containing pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABPqkBR3kduhc3L41_fXjRhS-QAiL9Gt37JaQFQ-D=4XZetdZA@mail.gmail.com>
Date:   Thu, 26 Jan 2017 14:26:12 -0800
From:   Stephane Eranian <eranian@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Andres Freund <andres@...razel.de>,
        "eranian@...il.com" <eranian@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...e.hu>,
        Anton Blanchard <anton@...abs.org>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: perf/jit doesn't cope well with mprotect() to jit containing pages

On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote:
>> The problem is that (quoted below) without that hack the subsequent
>> mmaps just expand the previous VMAs which leads to perf loosing its
>> (address,range) -> symbol mappings for previously (in the same expanded
>> range) known symbols.
>
> I'm assuming this is the userspace tool doing that, right?
>
> Acme, is that something we can cure? Instead of throwing away eveything
> known of the previous map, merge them when they grow?
>
> So I think the problem was that we don't track munmap(), so if you see
> two overlapping mappings, we have no clue and assume an munmap() has
> happened or something. I can't really remember, its been many many years
> since I wrote all that :-(

But perf report takes care of overlapping mmaps normally,
see util/map.c:map_groups__fixup_overlappings

VMA merging does not change anything at the user level.
The kernel will see two mmaps and so will perf record and perf report.
This is what you have. In the samples I quoted from your example, this
is what should happen. If it does not then there is something wrong in
perf report.


In the case of Java, if I recall, there is a single large mmap for the
code cache
and it works fine.