From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752123AbbLHS5n (ORCPT ); Tue, 8 Dec 2015 13:57:43 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:38598 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751818AbbLHS5m (ORCPT ); Tue, 8 Dec 2015 13:57:42 -0500 Date: Tue, 8 Dec 2015 19:57:38 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Dmitry Vyukov , Ingo Molnar , Arnaldo Carvalho de Melo , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin Subject: Re: use-after-free in __perf_install_in_context Message-ID: <20151208185737.GB3004@gmail.com> References: <20151208162227.GB6357@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151208162227.GB6357@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Fri, Dec 04, 2015 at 09:04:35PM +0100, Dmitry Vyukov wrote: > > Hello, > > > > While running syzkaller fuzzer I am seeing lots of the following > > use-after-free reports. Unfortunately all my numerous attempts to > > reproduce them in a controlled environment failed. They pop up during > > fuzzing periodically (once in several hours in a single VM), but > > whenever I try to stress-replay what happened in the VM before the > > report, the use-after-free does not reproduce. > > Typical that :/ > > > Can somebody knowledgeable in perf subsystem look at the report? Maybe > > it is possible to figure out what happened based purely on the report. > > I can pretty reliably test any proposed fixes. > > So I'm still going over the code, but meanwhile I tried reproducing this > using the perf_fuzzer and some debug code, but no luck with that. > > Since you seem to be able to reproduce, could you do a run with the > below patch in to see if it tickles something? Btw., could we add more redundancy / debug code to the refcounting code? It seems to be a frequent source of very hard to find/fix races/bugs - so it should be ripe for some extra debug infrastructure ... Thanks, Ingo