From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751176AbdAQNrR (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Jan 2017 08:47:17 -0500
Received: from Galois.linutronix.de ([146.0.238.70]:44860 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750982AbdAQNrQ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Jan 2017 08:47:16 -0500
Date: Tue, 17 Jan 2017 14:46:10 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Vikas Shivappa <vikas.shivappa@linux.intel.com>
cc: vikas.shivappa@intel.com, davidcc@google.com, eranian@google.com,
        linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com,
        mingo@kernel.org, peterz@infradead.org, ravi.v.shankar@intel.com,
        tony.luck@intel.com, fenghua.yu@intel.com, andi.kleen@intel.com,
        h.peter.anvin@intel.com
Subject: Re: [PATCH 05/12] x86/cqm,perf/core: Cgroup support prepare
In-Reply-To: <1483740005-23499-6-git-send-email-vikas.shivappa@linux.intel.com>
Message-ID: <alpine.DEB.2.20.1701171439210.3495@nanos>
References: <1483740005-23499-1-git-send-email-vikas.shivappa@linux.intel.com> <1483740005-23499-6-git-send-email-vikas.shivappa@linux.intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 6 Jan 2017, Vikas Shivappa wrote:
> @@ -741,7 +741,13 @@ static int intel_cqm_event_init(struct perf_event *event)
>  	INIT_LIST_HEAD(&event->hw.cqm_group_entry);
>  	INIT_LIST_HEAD(&event->hw.cqm_groups_entry);
>  
> -	event->destroy = intel_cqm_event_destroy;

I missed this in the first round, but tripped over it when looking at one
of the follow up patches.

How is that supposed to work?

1) intel_cqm_event_destroy() is still in the code and unused which emits a
   compiler warning, but that can obviously be ignored for a good measure.

2) How would any testing of this mess actually work?

   Not all all. Nothing ever tears down an event. So you just leave
   everything hanging around probably with dangling pointers left and
   right.

So now the 'Tests: Same as before.' in the so called changelog makes sense:

   'Same as before' means: Completely untested and broken.

Thanks,

	tglx