Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751194AbcCHTg3 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 8 Mar 2016 14:36:29 -0500
Received: from mga04.intel.com ([192.55.52.120]:28466 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751075AbcCHTgU (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 8 Mar 2016 14:36:20 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,557,1449561600"; 
   d="scan'208";a="919603758"
Date: Tue, 8 Mar 2016 11:36:58 -0800 (PST)
From: Vikas Shivappa <vikas.shivappa@intel.com>
X-X-Sender: vikas@vshiva-Udesk
To: Thomas Gleixner <tglx@linutronix.de>
cc: Vikas Shivappa <vikas.shivappa@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.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, h.peter.anvin@intel.com
Subject: Re: [PATCH 3/6] x86/mbm: Intel Memory B/W Monitoring enumeration
 and init
In-Reply-To: <alpine.DEB.2.11.1603081023180.6083@nanos>
Message-ID: <alpine.DEB.2.10.1603081136320.27741@vshiva-Udesk>
References: <1456876108-28770-4-git-send-email-vikas.shivappa@linux.intel.com> <1456962966-29395-1-git-send-email-vikas.shivappa@linux.intel.com> <alpine.DEB.2.11.1603030834180.3597@nanos> <alpine.DEB.2.10.1603031025390.32152@vshiva-Udesk>
 <alpine.DEB.2.11.1603031937210.3597@nanos> <alpine.DEB.2.11.1603081023180.6083@nanos>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1430
Lines: 53



On Tue, 8 Mar 2016, Thomas Gleixner wrote:

> On Thu, 3 Mar 2016, Thomas Gleixner wrote:
>> On Thu, 3 Mar 2016, Vikas Shivappa wrote:
>>
>>>
>>>
>>> On Wed, 2 Mar 2016, Thomas Gleixner wrote:
>>>
>>>> On Wed, 2 Mar 2016, Vikas Shivappa wrote:
>>>>> +	if (cqm_enabled && mbm_enabled)
>>>>> +		intel_cqm_events_group.attrs = intel_cmt_mbm_events_attr;
>>>>> +	else if (!cqm_enabled && mbm_enabled)
>>>>> +		intel_cqm_events_group.attrs = intel_mbm_events_attr;
>>>>> +	else if (cqm_enabled && !mbm_enabled)
>>>>> +		intel_cqm_events_group.attrs = intel_cqm_events_attr;
>>>>> +
>>>>>  	ret = perf_pmu_register(&intel_cqm_pmu, "intel_cqm", -1);
>>>>>  	if (ret) {
>>>>>  		pr_err("Intel CQM perf registration failed: %d\n", ret);
>>>>>  		goto out;
>>>>
>>>> So what cleans up mbm_local and mbm_total in that case?
>>>
>>> I put all the cleanup code in the cqm_cleanup .. - please see copy below
>>
>> Ok, missed that.
>>
>>> @@ -1331,6 +1427,39 @@ static void cqm_cleanup(void)
>>>                 kfree(cqm_rmid_ptrs[r]);
>>>
>>>         kfree(cqm_rmid_ptrs);
>>> +       kfree(mbm_local);
>>> +       kfree(mbm_total);
>>> +       mbm_enabled = false;
>>> +       cqm_enabled = false;
>>> +}
>
> After looking at it closely, you really need a separate mbm_cleanup()
> function, so you can utilize it from mbm_init() and in the exit path.

Will fix and seperate the mbm and cqm cleanups..

Thanks,
Vikas

>
> Thanks,
>
> 	tglx
>