Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp90505pxb; Tue, 14 Sep 2021 19:38:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoeHu4eVDtPhAnbIzzUCMYmeDoUQuY+FIVh0o/9rT1CobJ13IXOG1TThJRKcblYy+Bk7SU X-Received: by 2002:a2e:814f:: with SMTP id t15mr17805230ljg.363.1631673513631; Tue, 14 Sep 2021 19:38:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631673513; cv=none; d=google.com; s=arc-20160816; b=URUDvdbuH4O4Pme/pBGHq16UYOEM97gxFeyhv/TAK+tGC6hdWJy1IFrskPs5A0Hj55 gMgZftYNXrdjcVg8sZ4J45UHAqS/UCbJRT1S5gAPUXsZMgbTNZy4ZbzSTbl0nef+uVF/ yOQPYINKZYK4qDBstaerzKrbb0kSj7IK8Nnv23YKILx/UzqKYy5RQ8qaU7hbjjJTHSld wkDRh2cVRTXlkxk9heYHUgrmk7wfsh8/8/sHeJJwybM39LctTnrTsYYixOQ3Va0CbAMK u0+uDkFxr+/kr7oxZxaH2lsbIoaglDy6BcjsaCzSPFknbG3RUYji5+FXYbJZnIhKsHUk uKcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=76ZKLtH3jb+yamtnnm6O5rBJq1QK01MRxUp7EEt003o=; b=MtzRUahtb6k0Sn2WSEWK5kmTO0DtnwcyOySSgcGjV8VanmpPyVA8u5boZ6PgS3XSHO PQ4IUKAoSed+19Tpc3n+wnlmqs2s7MjRuj33CLbmyjXMu1L8xubNa3nDfQfqaH48dzUb EzRNniNqBpsNvn+wOKieIGLRIzCB3OovXuGr1Jsfwh8Nw/UVvFTEFEFUvA+TT5stv1uR RSBRLPKnVTZ+9fJvKlHSXmXyv2ahC5TIlER7SMzNqm7LQ6W2TCdXjduQrSJYkp9gksiR NDy5BOkFyxFMRpZRPgwb+wfvLVCGe1ykqPNhjIlkzWHsteCwIngJob6KMLd9359PzvWR xMzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z28si13396159ljm.259.2021.09.14.19.38.04; Tue, 14 Sep 2021 19:38:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229758AbhIOChs (ORCPT + 99 others); Tue, 14 Sep 2021 22:37:48 -0400 Received: from out30-56.freemail.mail.aliyun.com ([115.124.30.56]:51533 "EHLO out30-56.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229594AbhIOChs (ORCPT ); Tue, 14 Sep 2021 22:37:48 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UoQrdxZ_1631673387; Received: from B-D1K7ML85-0059.local(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0UoQrdxZ_1631673387) by smtp.aliyun-inc.com(127.0.0.1); Wed, 15 Sep 2021 10:36:28 +0800 Subject: Re: [Ocfs2-devel] [PATCH v2] ocfs2: Fix handle refcount leak in two exception handling paths From: Joseph Qi To: Chenyuan Mi , akpm Cc: Xin Tan , Xiyu Yang , yuanxzhang@fudan.edu.cn, linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com, Wengang Wang References: <20210908102055.10168-1-cymi20@fudan.edu.cn> <06d9e055-29b9-731c-5a36-d888f2c83188@linux.alibaba.com> Message-ID: Date: Wed, 15 Sep 2021 10:36:27 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <06d9e055-29b9-731c-5a36-d888f2c83188@linux.alibaba.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andrew, Now there is no objection on this patch. Would you please pick it into your -mm tree? Thanks. Joseph On 9/8/21 6:51 PM, Joseph Qi wrote: > > > On 9/8/21 6:20 PM, Chenyuan Mi wrote: >> The reference counting issue happens in two exception handling paths >> of ocfs2_replay_truncate_records(). When executing these two exception >> handling paths, the function forgets to decrease the refcount of handle >> increased by ocfs2_start_trans(), causing a refcount leak. >> >> Fix this issue by using ocfs2_commit_trans() to decrease the refcount >> of handle in two handling paths. >> >> Signed-off-by: Chenyuan Mi >> Signed-off-by: Xiyu Yang >> Signed-off-by: Xin Tan > > Reviewed-by: Joseph Qi >> --- >> fs/ocfs2/alloc.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/fs/ocfs2/alloc.c b/fs/ocfs2/alloc.c >> index f1cc8258d34a..b05fde7edc3a 100644 >> --- a/fs/ocfs2/alloc.c >> +++ b/fs/ocfs2/alloc.c >> @@ -5940,6 +5940,7 @@ static int ocfs2_replay_truncate_records(struct ocfs2_super *osb, >> status = ocfs2_journal_access_di(handle, INODE_CACHE(tl_inode), tl_bh, >> OCFS2_JOURNAL_ACCESS_WRITE); >> if (status < 0) { >> + ocfs2_commit_trans(osb, handle); >> mlog_errno(status); >> goto bail; >> } >> @@ -5964,6 +5965,7 @@ static int ocfs2_replay_truncate_records(struct ocfs2_super *osb, >> data_alloc_bh, start_blk, >> num_clusters); >> if (status < 0) { >> + ocfs2_commit_trans(osb, handle); >> mlog_errno(status); >> goto bail; >> } >> > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel >