Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4880568pxj; Wed, 9 Jun 2021 04:19:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpOkv1VrVQ/g5a0NEFmDACfuFH3ox6jrM1MQh9BfD7WptpUQMMwoL6tPNwmMSwyPhDjdCF X-Received: by 2002:a17:906:c141:: with SMTP id dp1mr28827154ejc.87.1623237576518; Wed, 09 Jun 2021 04:19:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623237576; cv=none; d=google.com; s=arc-20160816; b=vSXuNUo7EPoN6v8g0W6jHxLjRu9SUOQFRIFanSfkMC1CgLGNe7aAFQhP/PuUCRdaZ2 Z/ocVinHxKP57m7uJ8Cc0stoGQGNDIAnR3ZZgHmtvhi/Q/PsjttAqHWnzV5Lv4odPxHE 5v4wNAaTozAKygKsuNSLkwkMcOSjk8nwNU8owREDXpLsusUR1sSOKE85wCB5Dg7JauMF Hhf8JapTrjCaiUdSiLhN6QhD1tpnksEm8mcZn4CC+Q7pGYI3EdBlKVpn8q8TXcpolzs0 WiRYjI0MTaPOr29dA1DR4wwbxSGT/uHqSD+2KKNf2JGjfTW3mr3zuJ+vDNSVfzA95MfM hFVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=kbvA2Tgbg8whYy0MsixaJOyW+ka+D3GD92J8FNhp48M=; b=UuyMEAgscue3Hgi9faRsd1iGOxp4Sw1dVBSR6E7/aPRcIVVt0om8DXyi64AVXb9hjx 8LkzJNZUUJgrPhyEIgfyApF+5o9SqcKJaRL8RrbcWe2XOk5v2vdHxAvkZbUtE0RcnPhh FFmrIE1m4P+z2ImN8GSFERIvAiJ5asRbZfUQSDwCXAMz0XMZPKFzrcfGihXKwvJ/rlZI j0wza2h3BsA5T5/I4N6QIolHmWmk5JAgpCPO+IEHdFagNJzdquU4g8KxtljtMvz8WMqj Svao2ttnVU6T17TVppZvLfbi4KNW7GrJmFy2hvcKy3Sh1QlUdqlIlUrb7M+KfA61vEo/ JMig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AvOEpoMJ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u23si2108030ejt.28.2021.06.09.04.19.13; Wed, 09 Jun 2021 04:19:36 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=AvOEpoMJ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236564AbhFHT0Y (ORCPT + 99 others); Tue, 8 Jun 2021 15:26:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:60190 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238211AbhFHTOU (ORCPT ); Tue, 8 Jun 2021 15:14:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9F9B16142C; Tue, 8 Jun 2021 18:50:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1623178212; bh=68GdZ998arAE01h8FdAc62IQtcrv7/RKbR8ZMV5Q5nc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AvOEpoMJmk1xtwW09XSl0FIzmDDUle7xYcRXGVIJEZLBen4xOdTsbJjepFx/rvW+p qHmBPb4FqrCM6tlvHSc2y8zGNumuqTcmboq3f0UU2ranxAmjRWBgjPUYvCekjBVEui 0uKOHvkW0GNUHnUIpZAjVBMtmew3HYMAJgT5S8dY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Ye Bin , Jan Kara , Theodore Tso Subject: [PATCH 5.12 117/161] ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed Date: Tue, 8 Jun 2021 20:27:27 +0200 Message-Id: <20210608175949.411745907@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210608175945.476074951@linuxfoundation.org> References: <20210608175945.476074951@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ye Bin commit 082cd4ec240b8734a82a89ffb890216ac98fec68 upstream. We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)." Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210506141042.3298679-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/extents.c | 43 +++++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 20 deletions(-) --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -3206,7 +3206,10 @@ static int ext4_split_extent_at(handle_t ext4_ext_mark_unwritten(ex2); err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags); - if (err == -ENOSPC && (EXT4_EXT_MAY_ZEROOUT & split_flag)) { + if (err != -ENOSPC && err != -EDQUOT) + goto out; + + if (EXT4_EXT_MAY_ZEROOUT & split_flag) { if (split_flag & (EXT4_EXT_DATA_VALID1|EXT4_EXT_DATA_VALID2)) { if (split_flag & EXT4_EXT_DATA_VALID1) { err = ext4_ext_zeroout(inode, ex2); @@ -3232,25 +3235,22 @@ static int ext4_split_extent_at(handle_t ext4_ext_pblock(&orig_ex)); } - if (err) - goto fix_extent_len; - /* update the extent length and mark as initialized */ - ex->ee_len = cpu_to_le16(ee_len); - ext4_ext_try_to_merge(handle, inode, path, ex); - err = ext4_ext_dirty(handle, inode, path + path->p_depth); - if (err) - goto fix_extent_len; - - /* update extent status tree */ - err = ext4_zeroout_es(inode, &zero_ex); - - goto out; - } else if (err) - goto fix_extent_len; - -out: - ext4_ext_show_leaf(inode, path); - return err; + if (!err) { + /* update the extent length and mark as initialized */ + ex->ee_len = cpu_to_le16(ee_len); + ext4_ext_try_to_merge(handle, inode, path, ex); + err = ext4_ext_dirty(handle, inode, path + path->p_depth); + if (!err) + /* update extent status tree */ + err = ext4_zeroout_es(inode, &zero_ex); + /* If we failed at this point, we don't know in which + * state the extent tree exactly is so don't try to fix + * length of the original extent as it may do even more + * damage. + */ + goto out; + } + } fix_extent_len: ex->ee_len = orig_ex.ee_len; @@ -3260,6 +3260,9 @@ fix_extent_len: */ ext4_ext_dirty(handle, inode, path + path->p_depth); return err; +out: + ext4_ext_show_leaf(inode, path); + return err; } /*