From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932802AbcFBMIb (ORCPT ); Thu, 2 Jun 2016 08:08:31 -0400 Received: from ozlabs.org ([103.22.144.67]:40630 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932344AbcFBMIa (ORCPT ); Thu, 2 Jun 2016 08:08:30 -0400 Message-ID: <1464869307.31709.1.camel@ellerman.id.au> Subject: Re: [PATCH 3/8] cpufreq: powerenv: Fix memory leak From: Michael Ellerman To: Viresh Kumar Cc: Rafael Wysocki , Benjamin Herrenschmidt , Paul Mackerras , linaro-kernel@lists.linaro.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Date: Thu, 02 Jun 2016 22:08:27 +1000 In-Reply-To: <20160602114311.GR3725@vireshk-i7> References: <1464865688.11826.1.camel@ellerman.id.au> <20160602112203.GO3725@vireshk-i7> <1464867465.11826.4.camel@ellerman.id.au> <20160602114311.GR3725@vireshk-i7> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-06-02 at 17:13 +0530, Viresh Kumar wrote: > On 02-06-16, 21:37, Michael Ellerman wrote: > > On Thu, 2016-06-02 at 16:52 +0530, Viresh Kumar wrote: > > > On 02-06-16, 21:08, Michael Ellerman wrote: > > > > On Wed, 2016-06-01 at 16:04 +0530, Viresh Kumar wrote: > > > > > > > > > The policy is copied (unnecessarily) and is never freed. Fix it by just > > > > > getting a reference to the existing policy structure and putting it > > > > > back. > > > > > > > > > > Signed-off-by: Viresh Kumar > > > > > > > > When was it broken, always? > > > > > > > > Cc: stable ? > > > > > > Its a small memory leak and its not that we will fail on something. So > > > didn't bother to add those details, but in case they are required: > > > > > > Cc: # 4.3+ > > > Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling") > > > > OK. I can't actually see where the copy is? > > > > But if we are leaking even a small amount of memory in a loop like that, in a > > function that's run semi-regularly, then it's going to add up eventually. > > Urg, it wasn't a memory leak actually. I misread. > > I somehow thought that cpufreq_get_policy() is also allocating memory > for the policy, but it just memcpy's it into the callers buffer. So, > that's not a problem really. > > This patch should be just dropped. Sorry for the noise. OK, no worries. cheers