linux-kernel - Re: "perf ftrace" segfault because ->cpus!=NULL but ->all

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] [day] [month] [year] [list]

Message-ID: <CAG48ez18J4m5_BppHLRidSYnLTt8K809Hqiv4bDiFz52u_=8hA@mail.gmail.com>
Date:   Thu, 9 Jan 2020 16:12:30 +0100
From:   Jann Horn <jannh@...gle.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: "perf ftrace" segfault because ->cpus!=NULL but ->all_cpus==NULL

On Thu, Jan 9, 2020 at 4:11 PM Arnaldo Carvalho de Melo
<arnaldo.melo@...il.com> wrote:
> Em Thu, Jan 09, 2020 at 12:37:14PM +0100, Jann Horn escreveu:
> > I was clumsily trying to use "perf ftrace" from git master (I might
> > very well be using it wrong), and it's falling over with a NULL deref.
> > I don't really understand the perf code, but it looks to me like it
> > might be related to Andi Kleen's refactoring that introduced
> > evlist->all_cpus?
>
> > I think the problem is that evlist_close() assumes that ->cpus!=NULL
> > implies ->all_cpus!=NULL, but perf_evlist__propagate_maps() doesn't
> > set ->all_cpus if the evlist is empty.
>
> > Here's the crash I encountered:
>
> I've reproduced it and Jiri provided a patch, I'll test it, meanwhile
> you could alternatively drop an 'f' and try 'perf trace' + 'perf probe'
> instead, perhaps that could be enough, some examples:
>
> [root@...co ~]# perf probe kmem_cache_alloc
> Added new event:
>   probe:kmem_cache_alloc (on kmem_cache_alloc)
>
> You can now use it in all perf tools, such as:
>
>         perf record -e probe:kmem_cache_alloc -aR sleep 1

Ah, thanks for the help. :)