[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1701171221150.15892@vshiva-Udesk>
Date: Tue, 17 Jan 2017 12:22:58 -0800 (PST)
From: Shivappa Vikas <vikas.shivappa@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>
cc: Vikas Shivappa <vikas.shivappa@...ux.intel.com>,
vikas.shivappa@...el.com, davidcc@...gle.com, eranian@...gle.com,
linux-kernel@...r.kernel.org, x86@...nel.org, hpa@...or.com,
mingo@...nel.org, peterz@...radead.org, ravi.v.shankar@...el.com,
tony.luck@...el.com, fenghua.yu@...el.com, andi.kleen@...el.com,
h.peter.anvin@...el.com
Subject: Re: [PATCH 05/12] x86/cqm,perf/core: Cgroup support prepare
On Tue, 17 Jan 2017, Thomas Gleixner wrote:
> 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.
The terminate is defined in next patch. Will fix this as we dont need all this
new api and the cgroup cqm specific structures can be freed with cgroup hooks
instead of creating this new one.
Thanks,
Vikas
>
> So now the 'Tests: Same as before.' in the so called changelog makes sense:
>
> 'Same as before' means: Completely untested and broken.
>
> Thanks,
>
> tglx
>
>
Powered by blists - more mailing lists