From patchwork Thu May 2 12:56:50 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Qi X-Patchwork-Id: 2511711 Return-Path: X-Original-To: patchwork-ocfs2-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by patchwork1.kernel.org (Postfix) with ESMTP id E76383FCA5 for ; Thu, 2 May 2013 13:01:09 +0000 (UTC) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r42D0tq6027698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 May 2013 13:00:56 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r42D0qcq029851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 May 2013 13:00:52 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1UXt80-0007sB-DE; Thu, 02 May 2013 06:00:52 -0700 Received: from acsinet22.oracle.com ([141.146.126.238]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1UXt7j-0007rq-An for ocfs2-devel@oss.oracle.com; Thu, 02 May 2013 06:00:36 -0700 Received: from userp1020.oracle.com (userp1020.oracle.com [156.151.31.79]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r42D0YuW020877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 May 2013 13:00:34 GMT Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by userp1020.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r42D0F6S018394 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 2 May 2013 13:00:17 GMT Received: from 172.24.2.119 (EHLO szxeml209-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id BBN49024; Thu, 02 May 2013 20:58:57 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 2 May 2013 20:57:17 +0800 Received: from [127.0.0.1] (10.135.64.116) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server id 14.1.323.7; Thu, 2 May 2013 20:57:07 +0800 Message-ID: <51826292.2000001@huawei.com> Date: Thu, 2 May 2013 20:56:50 +0800 From: Joseph Qi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andrew Morton X-Originating-IP: [10.135.64.116] X-CFilter-Loop: Reflected X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=119.145.14.64 ct-class=R3 ct-vol1=0 ct-vol2=6 ct-vol3=5 ct-risk=10 ct-spam1=0 ct-spam2=0 ct-bulk=90 rcpts=1 size=2654 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.0 cv=Y/TRQ2iN c=1 sm=1 a=6YMIiCGU//PUEf62qScyBg==:17 a=0JQp9YiEBiYA:10 a=_nfIMGA1H_4A:10 a=Xdr-nIGslYIA:10 a=O9dq5j03pVQA:10 a=i0EeH86SAAAA:8 a=6rOScXfMv3IA:10 a=VwQbUJbxAAAA:8 a=yPCof4ZbAAAA:8 a=mfZYahnc0snsV12mlggA:9 a=QEXdDO2ut3YA :10 a=hPjdaMEvmhQA:10 a=7DSvI1NPTFQA:10 a=_W_S_7VecoQA:10 a=KaKiw5nSQ2-u-fp3:21 a=6YMIiCGU//PUEf62qScyBg==:117 X-Sendmail-CT-Classification: not spam X-Sendmail-CT-RefID: str=0001.0A090204.51826372.0008:SCFSTAT1612107, ss=1, re=-1.801, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: Mark Fasheh , "ocfs2-devel@oss.oracle.com" Subject: [Ocfs2-devel] [PATCH v2] ocfs2: fix possible memory leak in dlm_process_recovery_data X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Source-IP: acsinet21.oracle.com [141.146.126.237] We found a possible memory leak in dlm_process_recovery_data when doing code review. In dlm_process_recovery_data, it creates newlock each time, but don't free when it is bad, and then it will lead to memory leak. Cc: stable@vger.kernel.org Signed-off-by: Joseph Qi Reviewed-by: Jie Liu --- fs/ocfs2/dlm/dlmrecovery.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ocfs2/dlm/dlmrecovery.c b/fs/ocfs2/dlm/dlmrecovery.c index eeac97b..9f08523 100644 --- a/fs/ocfs2/dlm/dlmrecovery.c +++ b/fs/ocfs2/dlm/dlmrecovery.c @@ -1974,6 +1974,10 @@ skip_lvb: res->lockname.len, res->lockname.name, ml->node); dlm_lockres_set_refmap_bit(dlm, res, ml->node); added++; + } else { + /* Free the new lock if it is bad */ + dlm_lock_put(newlock); + newlock = NULL; } spin_unlock(&res->spinlock); }