From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751318AbcFGXUN (ORCPT ); Tue, 7 Jun 2016 19:20:13 -0400 Received: from m15-14.126.com ([220.181.15.14]:29539 "EHLO m15-14.126.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbcFGXUL (ORCPT ); Tue, 7 Jun 2016 19:20:11 -0400 X-Greylist: delayed 1808 seconds by postgrey-1.27 at vger.kernel.org; Tue, 07 Jun 2016 19:20:09 EDT X-Originating-IP: [113.200.155.185] Date: Wed, 8 Jun 2016 06:49:48 +0800 (CST) From: "Tiezhu Yang" To: "James Bottomley" Cc: martin.petersen@oracle.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] scsi: ufs: fix potential memory leak X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160223(81157.8522) Copyright (c) 2002-2016 www.mailtech.cn 126com In-Reply-To: <1465326728.2310.39.camel@HansenPartnership.com> References: <1a5ff649.111.1552c05f371.Coremail.kernelpatch@126.com> <1465326728.2310.39.camel@HansenPartnership.com> Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Message-ID: <770e1f6d.59f.1552d0ebd55.Coremail.kernelpatch@126.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: DsqowAC38nCNT1dXIcMJAA--.55123W X-CM-SenderInfo: xnhu0vxosd3ubk6rjloofrz/1tbiWw2B9VPNCmSJHAAAsH X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u57NKJpS002387 At 2016-06-08 03:12:08, "James Bottomley"  wrote: >On Wed, 2016-06-08 at 02:00 +0800, Tiezhu Yang wrote: >> There exists potential memory leak in ufshcd_parse_clock_info(), >> this patch fixes it. > >What makes you think there's a leak here?  These are all devm_ >allocations, so they're all freed when the device is.  If an error is >returned, the device is released and the memory freed. > >You can argue that on successful initialization, there's no need to >keep the clkfreq array but this patch isn't the way you'd change that. > >James > OK, thanks. I will send a v2 patch.