[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1701172230230.3645@nanos>
Date: Tue, 17 Jan 2017 22:31:43 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Shivappa Vikas <vikas.shivappa@...el.com>
cc: Vikas Shivappa <vikas.shivappa@...ux.intel.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, Shivappa Vikas wrote:
> 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.
I know and that does not make it any better. It's broken, end of story.
Thanks,
tglx
Powered by blists - more mailing lists