From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 106F93FFE; Tue, 23 Jan 2024 00:49:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705970942; cv=none; b=BMVt+HPbPHLKi1pcBXwSLBbvsf/LTTw9Yqf3CV4Jto45kwyK/4DQK9vxGmO5CQAlB5OsHntuYEyyXwO4VWLq4jLbc3FgcskcR1DSZRr8Bol9/s0WRq1/tz0Q0BvO1V/j0V1Fb74X4sHm+XlScf5YJmt4fhFowi0uqBrW7HtmTLw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705970942; c=relaxed/simple; bh=pCeV1kJ7rdpj8EbpJL6BGok+i4I8Ghstow2nucdyulE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gdWs1uJKYT3IavU5ij2F13uohKOHnuT1DEjkTUVxWeJoJ1nCwXVmYNq8oO1WeyCqcxd96D3wlg0VDpRxc0mD6/9pfVCVJxNtJJ6+RDokNSJK7tuIPjlfB8JOlr7sbPQf6+jUUTmox/uhOH85x4cAiGVZ4cR5ScBIOIRMXrcNxNE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=N+ZFaizx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="N+ZFaizx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85741C43390; Tue, 23 Jan 2024 00:49:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1705970941; bh=pCeV1kJ7rdpj8EbpJL6BGok+i4I8Ghstow2nucdyulE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N+ZFaizxBOdvvRzFqi8u15DBKdH2pOn1TMsW62Vjp4GQBvDLmaR9d8Fo/LcLtx8Dm 4zVwTmJRzed+5T6opttr1uGFTeYOFs70YH8oUNZL+RVYnA+GFZJLrUMmknybzP5X4e dEE5emFNY//KlvSdVO9I81OmntsIn+ZrD2m4ioyQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ye Bin , Jan Kara , Theodore Tso , Sasha Levin Subject: [PATCH 5.10 025/286] jbd2: fix soft lockup in journal_finish_inode_data_buffers() Date: Mon, 22 Jan 2024 15:55:31 -0800 Message-ID: <20240122235732.988415316@linuxfoundation.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240122235732.009174833@linuxfoundation.org> References: <20240122235732.009174833@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ye Bin [ Upstream commit 6c02757c936063f0631b4e43fe156f8c8f1f351f ] There's issue when do io test: WARN: soft lockup - CPU#45 stuck for 11s! [jbd2/dm-2-8:4170] CPU: 45 PID: 4170 Comm: jbd2/dm-2-8 Kdump: loaded Tainted: G OE Call trace: dump_backtrace+0x0/0x1a0 show_stack+0x24/0x30 dump_stack+0xb0/0x100 watchdog_timer_fn+0x254/0x3f8 __hrtimer_run_queues+0x11c/0x380 hrtimer_interrupt+0xfc/0x2f8 arch_timer_handler_phys+0x38/0x58 handle_percpu_devid_irq+0x90/0x248 generic_handle_irq+0x3c/0x58 __handle_domain_irq+0x68/0xc0 gic_handle_irq+0x90/0x320 el1_irq+0xcc/0x180 queued_spin_lock_slowpath+0x1d8/0x320 jbd2_journal_commit_transaction+0x10f4/0x1c78 [jbd2] kjournald2+0xec/0x2f0 [jbd2] kthread+0x134/0x138 ret_from_fork+0x10/0x18 Analyzed informations from vmcore as follows: (1) There are about 5k+ jbd2_inode in 'commit_transaction->t_inode_list'; (2) Now is processing the 855th jbd2_inode; (3) JBD2 task has TIF_NEED_RESCHED flag; (4) There's no pags in address_space around the 855th jbd2_inode; (5) There are some process is doing drop caches; (6) Mounted with 'nodioread_nolock' option; (7) 128 CPUs; According to informations from vmcore we know 'journal->j_list_lock' spin lock competition is fierce. So journal_finish_inode_data_buffers() maybe process slowly. Theoretically, there is scheduling point in the filemap_fdatawait_range_keep_errors(). However, if inode's address_space has no pages which taged with PAGECACHE_TAG_WRITEBACK, will not call cond_resched(). So may lead to soft lockup. journal_finish_inode_data_buffers filemap_fdatawait_range_keep_errors __filemap_fdatawait_range while (index <= end) nr_pages = pagevec_lookup_range_tag(&pvec, mapping, &index, end, PAGECACHE_TAG_WRITEBACK); if (!nr_pages) break; --> If 'nr_pages' is equal zero will break, then will not call cond_resched() for (i = 0; i < nr_pages; i++) wait_on_page_writeback(page); cond_resched(); To solve above issue, add scheduling point in the journal_finish_inode_data_buffers(); Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20231211112544.3879780-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/jbd2/commit.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c index fa24b407a9dc..db137671a41f 100644 --- a/fs/jbd2/commit.c +++ b/fs/jbd2/commit.c @@ -300,6 +300,7 @@ static int journal_finish_inode_data_buffers(journal_t *journal, if (!ret) ret = err; } + cond_resched(); spin_lock(&journal->j_list_lock); jinode->i_flags &= ~JI_COMMIT_RUNNING; smp_mb(); -- 2.43.0