From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030191AbcFBLnY (ORCPT ); Thu, 2 Jun 2016 07:43:24 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:35621 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932294AbcFBLnU (ORCPT ); Thu, 2 Jun 2016 07:43:20 -0400 Date: Thu, 2 Jun 2016 17:13:11 +0530 From: Viresh Kumar To: Michael Ellerman 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 Subject: Re: [PATCH 3/8] cpufreq: powerenv: Fix memory leak Message-ID: <20160602114311.GR3725@vireshk-i7> References: <1464865688.11826.1.camel@ellerman.id.au> <20160602112203.GO3725@vireshk-i7> <1464867465.11826.4.camel@ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1464867465.11826.4.camel@ellerman.id.au> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- viresh