From patchwork Mon Oct 24 11:27:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 9038 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp442051wru; Mon, 24 Oct 2022 06:06:52 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4nfLI7aOfLxZPBGia0QXx07DGH6+53kax0YBlVXuS+0JbiBs+wv+7epKUTTaoJ6x84L9YT X-Received: by 2002:a17:90b:4b0c:b0:20d:233f:5dea with SMTP id lx12-20020a17090b4b0c00b0020d233f5deamr38045907pjb.241.1666616811715; Mon, 24 Oct 2022 06:06:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666616811; cv=none; d=google.com; s=arc-20160816; b=Q7HO5gKNZkj9DWoe6jrnP2CVlZizBjNv8HZ0KugxgK+OmoNtRd8NGUFUcskerqDR6I 32scSxC0IqA6idSnIKo5RLw/bXK5a+jcTlCLX2XBLy3j384p+QmrvC/0AK3GgtXPtp5f jv9NP5z4Jg/ibhYT9Tqc6Pb+FX47qM/cZLz2ftG7d/yiN+N+fErp8ztF1hRxMuEnWD/R NUebmK8NvoBagAcmx1u4aLjyKZwi9a4rSy7Lq5MxKPVDeXQHzJIwgjedz8pM8zlRPPFA RCuMnthc4P2+1t2u2zY26NY22EihhlmGgbGsJOBgLWl/vMsplj1ukUkjRa+iwgjL/J9c 34vA== 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=OtRnNJ81IBt3HCmM1zj5pUTAG8iic278N0LUgGLc438=; b=lCTkL5pN8LqsNraoT2BU3klm4wQX2vX9B0laY6yjGMVtzMcu5ohttPdu4DeQtdXnox MtLESpJ3duxz9xovRgWNXqzuFNJ8N8oog2e617sIKVnU6CnVfIzylae+9FZBwfDTyrq8 hGqcaXYi9KtDHsLMgwU4RyYVNs32E+tlG7Ar3TIzBq7qbXS+SMmOfnQ23Om1jz0tB3tj k+MJNZ1EfmexW3/hAGr/pEct7uRrhPMST5tqoYTVuCv9ygkBgd4eNGlgyH6QA3an7Zd0 ZiicpiVnzqncKQcSV5Tykt/SeteGS+m4VGo/wMtsxLleUx6FPnnXa6t0CNC6SWniE29E FSQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oQ5seF0o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w4-20020a656944000000b00460cb60836esi35437220pgq.659.2022.10.24.06.06.34; Mon, 24 Oct 2022 06:06:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oQ5seF0o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S235275AbiJXNFX (ORCPT + 99 others); Mon, 24 Oct 2022 09:05:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234955AbiJXNCT (ORCPT ); Mon, 24 Oct 2022 09:02:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 703092C10F; Mon, 24 Oct 2022 05:19:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D831A61218; Mon, 24 Oct 2022 12:18:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAC0EC433D6; Mon, 24 Oct 2022 12:18:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666613921; bh=vwwx69rsb2FIxihCa6bfk7flG0j7C7NEHsW48/SnURQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oQ5seF0om/VALfHykfCZe1ITSWGWJZ3coHEGjFq3lw31hpbeIBn4kTRv17mGVV01F RprSpuvutmizxpSoYmOfdwBo8aCnySFBx/XJC5v6ImhvkOpClgFamtjN31KWS6Da91 J2EsPrT7b6xk7JZDMEpHVGxDGyiIetW7JDNeOZRs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Zhang Yi , Jan Kara , Theodore Tso Subject: [PATCH 5.10 065/390] ext4: ext4_read_bh_lock() should submit IO if the buffer isnt uptodate Date: Mon, 24 Oct 2022 13:27:42 +0200 Message-Id: <20221024113025.388075487@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113022.510008560@linuxfoundation.org> References: <20221024113022.510008560@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747574389788035770?= X-GMAIL-MSGID: =?utf-8?q?1747574389788035770?= From: Zhang Yi commit 0b73284c564d3ae4feef4bc920292f004acf4980 upstream. Recently we notice that ext4 filesystem would occasionally fail to read metadata from disk and report error message, but the disk and block layer looks fine. After analyse, we lockon commit 88dbcbb3a484 ("blkdev: avoid migration stalls for blkdev pages"). It provide a migration method for the bdev, we could move page that has buffers without extra users now, but it lock the buffers on the page, which breaks the fragile metadata read operation on ext4 filesystem, ext4_read_bh_lock() was copied from ll_rw_block(), it depends on the assumption of that locked buffer means it is under IO. So it just trylock the buffer and skip submit IO if it lock failed, after wait_on_buffer() we conclude IO error because the buffer is not uptodate. This issue could be easily reproduced by add some delay just after buffer_migrate_lock_buffers() in __buffer_migrate_folio() and do fsstress on ext4 filesystem. EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #73193: comm fsstress: reading directory lblock 0 EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #75334: comm fsstress: reading directory lblock 0 Fix it by removing the trylock logic in ext4_read_bh_lock(), just lock the buffer and submit IO if it's not uptodate, and also leave over readahead helper. Cc: stable@kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220831074629.3755110-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/super.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -188,19 +188,12 @@ int ext4_read_bh(struct buffer_head *bh, int ext4_read_bh_lock(struct buffer_head *bh, int op_flags, bool wait) { - if (trylock_buffer(bh)) { - if (wait) - return ext4_read_bh(bh, op_flags, NULL); + lock_buffer(bh); + if (!wait) { ext4_read_bh_nowait(bh, op_flags, NULL); return 0; } - if (wait) { - wait_on_buffer(bh); - if (buffer_uptodate(bh)) - return 0; - return -EIO; - } - return 0; + return ext4_read_bh(bh, op_flags, NULL); } /* @@ -247,7 +240,8 @@ void ext4_sb_breadahead_unmovable(struct struct buffer_head *bh = sb_getblk_gfp(sb, block, 0); if (likely(bh)) { - ext4_read_bh_lock(bh, REQ_RAHEAD, false); + if (trylock_buffer(bh)) + ext4_read_bh_nowait(bh, REQ_RAHEAD, NULL); brelse(bh); } }