From nobody Thu Apr 9 03:28:36 2026 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 868FC36D9FF for ; Wed, 11 Mar 2026 09:11:33 +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=1773220293; cv=none; b=VC+UFMF7NVWPIIuPyBjg7yVwCiU2HF9Xvy7E8J5veHHWXrpyyOOMvK70oH2323mj3FE1oxG23kbc6pO7RuyrYn96GYbnA5+WaC60B+82yoyK1zTiZ7BB+CRkLjwmuuhMGTT9RfsMNGrbvqMKcQH01nlvdTV+pHLzH6obwAwRamo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773220293; c=relaxed/simple; bh=Bk6Za+FR91Hj5mP/s3GgDxQNXtTe/Vg7T8Hbggv/lEs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=dG4Ta80dAcHrjV1oBFPUl0Zti3vqcUr3V24WrNioiemL9RR21wJPsWwcqk9UW8VmhlpIoThyqyqJH4KprB/cooPDhhW7njUuVz//mzbd11hJQ58rjiYmqgA6nLgVTiF2/epYNlacSMpXKUMwmFXMl7odX+iDYYRkoJv/JvPoNTE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YtyjDYMd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YtyjDYMd" Received: by smtp.kernel.org (Postfix) with ESMTPS id 05940C4CEF7; Wed, 11 Mar 2026 09:11:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773220293; bh=Bk6Za+FR91Hj5mP/s3GgDxQNXtTe/Vg7T8Hbggv/lEs=; h=From:Date:Subject:To:Cc:Reply-To:From; b=YtyjDYMdnE+TtglJRED719Y6o9DWZN83tBMCtyiIbdZe/ws3/43x5ZTz93ZY+26bA PEQs5pWHKswhMF/j4HCEZRB383d0ZrEJj/OGAP8qkGAnxeG2UyC5DhFv/bOzdvnS5A KBnufpKGUq5axdgnAkEUe920m/DFJELCaF0hiZg/zoaSYOGnhE5Rm2rlhuVERZHiO3 76HLWFeMlzNglAI9QYAuN0rBiRezAiWwMGve7r905NzlrYtMJSZkVr8Owqp5A21RFm G9+xLiC5uUWrMvvkzWYB4ZjNPpnBY1XU2WEqTOtjf+ktJZajJOPfhJwWlCghlsPZo+ 66t9YKNz5YCww== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E627EFD0649; Wed, 11 Mar 2026 09:11:32 +0000 (UTC) From: Jiucheng Xu via B4 Relay Date: Wed, 11 Mar 2026 17:11:31 +0800 Subject: [PATCH v2] erofs: add GFP_NOIO in the bio completion if needed Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260311-origin-dev-v2-1-0657cff690eb@amlogic.com> X-B4-Tracking: v=1; b=H4sIAMIxsWkC/23MQQ7CIBCF4as0s3YMIKXWlfcwXTR0oJPY0oAhm oa7i127/F/yvh0SRaYEt2aHSJkTh7WGOjVg53H1hDzVBiWUERcpMUT2vOJEGaXtjWm7/qqEhnr YIjl+H9hjqD1zeoX4Oewsf+tfJkuUqEWrNDnROSfu4/IMnu3ZhgWGUsoXgsB0KaYAAAA= X-Change-ID: 20260311-origin-dev-1c9665798204 To: Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, jianxin.pan@amlogic.com, tuan.zhang@amlogic.com, Jiucheng Xu , Gao Xiang X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1773220291; l=2158; i=jiucheng.xu@amlogic.com; s=20250821; h=from:subject:message-id; bh=YPPl1F3AUiL8XQFRy+eFl96JoDCQD8dYm64Zhy8f3cs=; b=E0Upnfawkos/3AiYtmkE1dhVITJ+d/UynPpDQdaMAbmgFjnARJUiz49lEt2IJfK9wcudy6z32 CLHKK3xLA6RBs+TwUnC/p76zC/qg7Zq4nsHsjVz3okyIOqW5cUMQBAJ X-Developer-Key: i=jiucheng.xu@amlogic.com; a=ed25519; pk=Q18IjkdWCCuncSplyu+dYqIrm+n42glvoLFJTQqpb2o= X-Endpoint-Received: by B4 Relay for jiucheng.xu@amlogic.com/20250821 with auth_id=498 X-Original-From: Jiucheng Xu Reply-To: jiucheng.xu@amlogic.com From: Jiucheng Xu The bio completion path in the process context (e.g. dm-verity) will directly call into decompression rather than trigger another workqueue context for minimal scheduling latencies, which can then call vm_map_ram() with GFP_KERNEL. Due to insufficient memory, vm_map_ram() may generate memory swapping I/O, which can cause submit_bio_wait to deadlock in some scenarios. Trimmed down the call stack, as follows: f2fs_submit_read_io submit_bio //bio_list is initialized. mmc_blk_mq_recovery z_erofs_endio vm_map_ram __pte_alloc_kernel __alloc_pages_direct_reclaim shrink_folio_list __swap_writepage submit_bio_wait //bio_list is non-NULL, hang!!! Use memalloc_noio_{save,restore}() to wrap up this path. Reviewed-by: Gao Xiang Signed-off-by: Jiucheng Xu Reviewed-by: Chao Yu --- Changes in v2: - Reword the commit message. - Link to v1: https://lore.kernel.org/r/20260311-origin-dev-v1-1-40524ef07f= f0@amlogic.com --- fs/erofs/zdata.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c index 3977e42b9516861bf3d59c072b6b8aaa6898dd8a..fe8121df9ef2f2404fc6e3f0fbb= d6367f9ec2c67 100644 --- a/fs/erofs/zdata.c +++ b/fs/erofs/zdata.c @@ -1445,6 +1445,7 @@ static void z_erofs_decompress_kickoff(struct z_erofs= _decompressqueue *io, int bios) { struct erofs_sb_info *const sbi =3D EROFS_SB(io->sb); + int gfp_flag; =20 /* wake up the caller thread for sync decompression */ if (io->sync) { @@ -1477,7 +1478,9 @@ static void z_erofs_decompress_kickoff(struct z_erofs= _decompressqueue *io, sbi->sync_decompress =3D EROFS_SYNC_DECOMPRESS_FORCE_ON; return; } + gfp_flag =3D memalloc_noio_save(); z_erofs_decompressqueue_work(&io->u.work); + memalloc_noio_restore(gfp_flag); } =20 static void z_erofs_fill_bio_vec(struct bio_vec *bvec, --- base-commit: 11439c4635edd669ae435eec308f4ab8a0804808 change-id: 20260311-origin-dev-1c9665798204 Best regards, --=20 Jiucheng Xu