From patchwork Thu Jan 25 02:41:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: piaojun X-Patchwork-Id: 10183483 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 18794601D5 for ; Thu, 25 Jan 2018 02:41:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E652628A64 for ; Thu, 25 Jan 2018 02:41:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DA7D128A6E; Thu, 25 Jan 2018 02:41:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 4BB9428A64 for ; Thu, 25 Jan 2018 02:41:56 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0P2dugx095652; Thu, 25 Jan 2018 02:41:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : from : message-id : date : mime-version : cc : subject : list-id : list-unsubscribe : list-archive : list-post : list-help : list-subscribe : content-type : content-transfer-encoding : sender; s=corp-2017-10-26; bh=A+hyM8ATbRiJSNio3h2qLs7AGf042kWcLiiAiGHt9CU=; b=VGSHmG9XJ2LRiG5CyYqHtdQ181cZuhL4LagSQ+btZ3O6J/fwgwuhjDrjvJCa72qESnKR vSa5t4wItA94RiO2EZXgDiQDD5OvboOkS5p7aqWtWnYM94lxcG5adMvm7J6InkHsxcdx 1krVrH3Z245bhUvyKPsN0WJCwwuPlEQRI9Z56V9hT8VSbXDWdBVzPYAt+sy9RUnpWLtc glfk+oyZ/CBba+ZpYnFiZLY7/2iNw18gaQVT5Nl9jejFHOvmsKpt0htmlhBHoVvptTDl Ah99gT/9Ia8Ba9B9EAF3odEfxmLK9C3WMKgOi8vgtf+pO520f6SdtxeOSfD2oAr6kX51 JQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2fq6ndr02u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jan 2018 02:41:22 +0000 Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0P2fIug017054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jan 2018 02:41:18 GMT Received: from localhost ([127.0.0.1] helo=lb-oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1eeXTa-0004mA-3i; Wed, 24 Jan 2018 18:41:18 -0800 Received: from userv0022.oracle.com ([156.151.31.74]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1eeXTW-0004lZ-Qr for ocfs2-devel@oss.oracle.com; Wed, 24 Jan 2018 18:41:15 -0800 Received: from userp2030.oracle.com (userp2030.oracle.com [156.151.31.89]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0P2fERi000407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 25 Jan 2018 02:41:14 GMT Received: from pps.filterd (userp2030.oracle.com [127.0.0.1]) by userp2030.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0P2bIpQ007061 for ; Thu, 25 Jan 2018 02:41:14 GMT Received: from huawei.com (szxga07-in.huawei.com [45.249.212.35] (may be forged)) by userp2030.oracle.com with ESMTP id 2fq2gk3hc9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Jan 2018 02:41:14 +0000 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 5E5209E1F8F8B; Thu, 25 Jan 2018 10:41:08 +0800 (CST) Received: from [10.177.253.249] (10.177.253.249) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.361.1; Thu, 25 Jan 2018 10:41:00 +0800 To: "akpm@linux-foundation.org" , Mark Fasheh , Joel Becker , Joseph Qi From: piaojun Message-ID: <5A6943BC.5010406@huawei.com> Date: Thu, 25 Jan 2018 10:41:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 X-Originating-IP: [10.177.253.249] X-CFilter-Loop: Reflected X-CLX-Shades: MLX X-CLX-Response: 1TFkXGxwZEQpMehcSHxEKWU0XZ2ZyEQpZSRcacRoQGncGGx4ZcRgcEBp3Bhg aBhoRClleF2hueREKSUYXRVhLSUZPdVpYRU5fSV5DRUQZdU9LEQpDThdvBxlrfBtfGH8HRUNJYG lwfWIaUFlFY0cfG1pEREBAWhEKWFwXHwQaBBsYHwdOSR0eExodTAUbGgQbGhoEHhIEHxAbHhofG hEKXlkXeERfQkYRCk1cFxwTHxEKTFoXaGlCTXsRCkNaFx4fBBgeEwQYGxgEGR8RCkJeFxsRCkRe Fx8RCkRJFxkRCkJGF2cTbWAbW2VCH359EQpCXBcaEQpCRRdmXGx7cGRiehJ8QxEKQk4XbEJIWVM aTWV4eB0RCkJMF29LGRISRFl5WxtfEQpCbBdjBUJSZkBiXlp7UhEKQkAXZmRrZFh6TGNlTxoRCk JYF2J9b3kBTxgZcHB7EQpaWBcYEQpwaBdufGAbT2JjXW5tHxAZGhEKcGgXZ3xrUB9+Rn8aRWQQG RoRCnBoF2IYRFp8X1sScHhmEBkaEQpwaBdiUnJjQEFiWURiUBAZGhEKcGgXZEl5HRhnTxlpZEgQ GRoRCnBsF2FJeUN6c0l4Z2xiEBkaEQptfhcaEQpYTRdLESA= X-PDR: PASS X-Source-IP: 45.249.212.35 X-ServerName: [45.249.212.35] X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:45.249.212.32 ip4:45.249.212.35 ip4:119.145.14.93 ip4:58.251.152.93 ip4:194.213.3.17 ip4:206.16.17.72 ip4:45.249.212.255 ip4:45.249.212.187/29 ip4:45.249.212.191 ~all X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8784 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=85 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=163 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250033 X-Spam: Clean Cc: "ocfs2-devel@oss.oracle.com" Subject: [Ocfs2-devel] [PATCH] ocfs2: return error when we attempt to access a dirty bh in jbd2 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-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8784 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250033 X-Virus-Scanned: ClamAV using ClamSMTP We should not reuse the dirty bh in jbd2 directly due to the following situation: 1. When removing extent rec, we will dirty the bhs of extent rec and truncate log at the same time, and hand them over to jbd2. 2. The bhs are not flushed to disk due to abnormal storage link. 3. After a while the storage link become normal. Truncate log flush worker triggered by the next space reclaiming found the dirty bh of truncate log and clear its 'BH_Write_EIO' and then set it uptodate in __ocfs2_journal_access(): ocfs2_truncate_log_worker ocfs2_flush_truncate_log __ocfs2_flush_truncate_log ocfs2_replay_truncate_records ocfs2_journal_access_di __ocfs2_journal_access // here we clear io_error and set 'tl_bh' uptodata. 4. Then jbd2 will flush the bh of truncate log to disk, but the bh of extent rec is still in error state, and unfortunately nobody will take care of it. 5. At last the space of extent rec was not reduced, but truncate log flush worker have given it back to globalalloc. That will cause duplicate cluster problem which could be identified by fsck.ocfs2. So we should return -EIO in case of ruining atomicity and consistency of space reclaim. Fixes: acf8fdbe6afb ("ocfs2: do not BUG if buffer not uptodate in __ocfs2_journal_access") Signed-off-by: Jun Piao Reviewed-by: Yiwen Jiang --- fs/ocfs2/journal.c | 45 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 35 insertions(+), 10 deletions(-) diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c index 3630443..d769ca2 100644 --- a/fs/ocfs2/journal.c +++ b/fs/ocfs2/journal.c @@ -666,21 +666,46 @@ static int __ocfs2_journal_access(handle_t *handle, /* we can safely remove this assertion after testing. */ if (!buffer_uptodate(bh)) { mlog(ML_ERROR, "giving me a buffer that's not uptodate!\n"); - mlog(ML_ERROR, "b_blocknr=%llu\n", - (unsigned long long)bh->b_blocknr); + mlog(ML_ERROR, "b_blocknr=%llu, b_state=0x%lx\n", + (unsigned long long)bh->b_blocknr, bh->b_state); lock_buffer(bh); /* - * A previous attempt to write this buffer head failed. - * Nothing we can do but to retry the write and hope for - * the best. + * We should not reuse the dirty bh directly due to the + * following situation: + * + * 1. When removing extent rec, we will dirty the bhs of + * extent rec and truncate log at the same time, and + * hand them over to jbd2. + * 2. The bhs are not flushed to disk due to abnormal + * storage link. + * 3. After a while the storage link become normal. + * Truncate log flush worker triggered by the next + * space reclaiming found the dirty bh of truncate log + * and clear its 'BH_Write_EIO' and then set it uptodate + * in __ocfs2_journal_access(): + * + * ocfs2_truncate_log_worker + * ocfs2_flush_truncate_log + * __ocfs2_flush_truncate_log + * ocfs2_replay_truncate_records + * ocfs2_journal_access_di + * __ocfs2_journal_access + * + * 4. Then jbd2 will flush the bh of truncate log to disk, + * but the bh of extent rec is still in error state, and + * unfortunately nobody will take care of it. + * 5. At last the space of extent rec was not reduced, + * but truncate log flush worker have given it back to + * globalalloc. That will cause duplicate cluster problem + * which could be identified by fsck.ocfs2. + * + * So we should return -EIO in case of ruining atomicity + * and consistency of space reclaim. */ if (buffer_write_io_error(bh) && !buffer_uptodate(bh)) { - clear_buffer_write_io_error(bh); - set_buffer_uptodate(bh); - } - - if (!buffer_uptodate(bh)) { + mlog(ML_ERROR, "A previous attempt to write this " + "buffer head failed\n"); unlock_buffer(bh); return -EIO; }