linux-kernel - Re: perf: perf_fuzzer WARNING: ring_buffer.c:546 __rb_free

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: <87a8d7o06b.fsf@ashishki-desk.ger.corp.intel.com>
Date:   Thu, 10 Nov 2016 16:54:20 +0200
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Vince Weaver <vincent.weaver@...ne.edu>,
        linux-kernel@...r.kernel.org
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: perf: perf_fuzzer WARNING: ring_buffer.c:546 __rb_free_aux

Vince Weaver <vincent.weaver@...ne.edu> writes:

> I thought we had sorted all the AUX issues, though interestingly this is 
> on a core2 system.
>
> this is:
>
> 	static void __rb_free_aux(struct ring_buffer *rb)
> 	{
>
>         /*
>          * Should never happen, the last reference should be dropped from
>          * perf_mmap_close() path, which first stops aux transactions (which
>          * in turn are the atomic holders of aux_refcount) and then does the
>          * last rb_free_aux().
>          */
>         WARN_ON_ONCE(in_atomic());
>
>
> [87078.464463] WARNING: CPU: 1 PID: 19400 at kernel/events/ring_buffer.c:546 __rb_free_aux+0x40/0xe8
> [87078.464466] CPU: 1 PID: 19400 Comm: perf_fuzzer Tainted: G        W       4.8.0+ #209
> [87078.464467] Hardware name: AOpen   DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BIOS 080015  10/19/2012
> [87078.464468]  ffff88011fc85b00c ffffffff812bc679c 0000000000000000c 0000000000000000c
> [87078.464469]  ffff88011fc85b40c ffffffff8104e0c8c 000002221fc85b98c ffff880119bf2700c
> [87078.464470]  ffff880119bf2700c 0000000000000000c 0000000000000001c 0000000000006108c
> [87078.464470] Call Trace:
> [87078.464471]  <NMI>  [<ffffffff812bc679>] dump_stack+0x4d/0x63
> [87078.464472]  [<ffffffff8104e0c8>] __warn+0xca/0xe5
> [87078.464473]  [<ffffffff8104e19f>] warn_slowpath_null+0x1d/0x1f
> [87078.464473]  [<ffffffff810fa055>] __rb_free_aux+0x40/0xe8
> [87078.464474]  [<ffffffff810fab48>] rb_free_aux+0x18/0x1a
> [87078.464475]  [<ffffffff810fad83>] perf_aux_output_end+0xca/0xd9
> [87078.464475]  [<ffffffff81009890>] intel_bts_interrupt+0xc4/0x11f
> [87078.464476]  [<ffffffff8100868c>] intel_pmu_handle_irq+0x75/0x3db

Yeah, this really shouldn't be happening. How reproducible is this? Any
clues that may help me reproduce it?

Meanwhile I'll stare at the code some more.

Regards,
--
Alex