From patchwork Thu Dec 21 22:42:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liu Bo X-Patchwork-Id: 10128543 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 64C93603B5 for ; Thu, 21 Dec 2017 23:45:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 577B129BDC for ; Thu, 21 Dec 2017 23:45:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4C66029E8F; Thu, 21 Dec 2017 23:45:54 +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=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4393729BDC for ; Thu, 21 Dec 2017 23:45:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755389AbdLUXpv (ORCPT ); Thu, 21 Dec 2017 18:45:51 -0500 Received: from aserp2120.oracle.com ([141.146.126.78]:57342 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184AbdLUXpl (ORCPT ); Thu, 21 Dec 2017 18:45:41 -0500 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBLNg61J083252 for ; Thu, 21 Dec 2017 23:45:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : subject : date : message-id : in-reply-to : references; s=corp-2017-10-26; bh=nUWmB0aVEr12LzEVRiLEsZ+8i1UdMOeJ0NEvT++tL8s=; b=O9rLVpjTjFIM6DCjtVIkguHDtM9OGobRM9oNrJUSMG8Tk4T8gg+B9KXFkJtUXnjwS1xr PKx4IqP1/z5B9Z/LgOqtyg+RngAhn6meFFSzHt8NcKMf/3PAritnzrBjn/ZkyMLsltSg ZOLp6hshXJuELiY42jWwU9WddvxxPEbTDMy2Y+AkIz6eT2mqUMlb/uJUovkKTEQSbkqE B29MXf+H9NlO0jGPRptk5TnCDP9UsnWuGF2FzeDALAOGZj1YkU5nhw9A2+xt6FdiA3ik Y5M41VV9VThM2/mRX4og63D0h7YBQOsb6D8Ps7sParjaFXGyATwwcRuZo1CBv9N383jE SQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2f0prs01b4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 21 Dec 2017 23:45:41 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBLNjea9010769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 21 Dec 2017 23:45:40 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vBLNjeCQ008955 for ; Thu, 21 Dec 2017 23:45:40 GMT Received: from dhcp-10-211-47-181.usdhcp.oraclecorp.com.com (/10.211.47.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Dec 2017 15:45:39 -0800 From: Liu Bo To: linux-btrfs@vger.kernel.org Subject: [PATCH 06/10] Btrfs: fix incorrect block_len in merge_extent_mapping Date: Thu, 21 Dec 2017 15:42:52 -0700 Message-Id: <20171221224256.18196-7-bo.li.liu@oracle.com> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20171221224256.18196-1-bo.li.liu@oracle.com> References: <20171221224256.18196-1-bo.li.liu@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8752 signatures=668651 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=5 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=775 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712210312 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP %block_len could be checked on deciding if two em are mergable. merge_extent_mapping() has only added the front pad if the front part of em gets truncated, but it's possible that the end part gets truncated. For both compressed extent and inline extent, em->block_len is not adjusted accordingly, while for regular extent, em->block_len always equals to em->len, hence this sets em->block_len with em->len. Signed-off-by: Liu Bo --- fs/btrfs/extent_map.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c index 51665de..6653b08 100644 --- a/fs/btrfs/extent_map.c +++ b/fs/btrfs/extent_map.c @@ -511,7 +511,7 @@ static int merge_extent_mapping(struct extent_map_tree *em_tree, if (em->block_start < EXTENT_MAP_LAST_BYTE && !test_bit(EXTENT_FLAG_COMPRESSED, &em->flags)) { em->block_start += start_diff; - em->block_len -= start_diff; + em->block_len = em->len; } return add_extent_mapping(em_tree, em, 0); }