From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F80D3DBD65 for ; Mon, 4 May 2026 13:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777901768; cv=none; b=LD7oSEaQTvy97iKuXY40Ld4cbKnTCuqmX+CRRiwO4Kb/bpORhijoUQMCJeqhfnBJo3PDPpYsRWgqxkypkummGh7h8Cg/OQJw/W6niibxftCqttDDZRH4xwAZOHbcWjOZd4XdE5KpZ+ptyoyKRsC7PhN3RW/KvkwrXkIJywvhL+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777901768; c=relaxed/simple; bh=BUDwAG1Lqz6heXETsaj0tF7GXkAD6gtHAsRK9OhAQmI=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=iDelBU6m6F8tgFxK25Tko4UEDNSsS8Ka9JEIAZnuXNc+8G8kfACsoBMfZBJ5LMPg6RRiWOid6xC52qPAdu/zbmrFQg6lNsEDG4zBrS22RyjfrNpGsd+wlMykSfVdcTaLDmzIIaN83zShDup/uoSjXB9z7vOLDC81sc5IZgqs8YE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ldPk/lJG; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ldPk/lJG" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c80203b9d7bso434907a12.0 for ; Mon, 04 May 2026 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777901767; x=1778506567; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8H2f2k29lbWfTJB0lfO3QkuoExzwF2AG5/RWyRyUBG8=; b=ldPk/lJGOx9+SI7GWH6761Azyx3QzWGKX8S7aKa4WAGlrvTwIEundHfrNsiCYRDJ3t OZqxRLEnurwkNSHTyhLvMSasN9TflMJR19bsL+rTWEhnpnc0ATHSrj7czYXUxRkgBACS 4T3v7augeP6xQshzp+pJVp1NCEqYUkKsdduGF1TsCoqtj/SKoPjXja1OP8RwW/idf9z5 TGPV0q+eEexZcH1ae1yaGmlyeVkVD2NjUVa0Gwu/BbSS5jKEPYbjMrytGPstpIOEUvEX qrxXPC5XpZyiyEBJ+KRVzynN+1oYSkLJxx6CnAzkR51CK4+w1SJO3GdgCblzf9sQOAsN q6KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777901767; x=1778506567; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8H2f2k29lbWfTJB0lfO3QkuoExzwF2AG5/RWyRyUBG8=; b=Q/636fGjUhcbaYYRlZLwDHlAxbwvbSKZhf1qPCrQBqAJc1jH2Q2ejwtKB/gVdfOdIq nGt4zSbVMus8sXbswb/9AvWLdSXun1RJwiqpzknXtyyZuQ9iJucqQjMKTlOPb7xDQ8b7 KzdwExPfJtqs5HJxQ+7q0gr+eVRnGdaBejL1FL83V4CHbxjVdVmOQVV+BpIwXCnxWFvB WpRl+gkWQTq3ykstQlPyLMTX057PHNwGUXYrC8q0L7sl3UTDZCQxCIzICGw26Gxjetmz qwvgO0/yEQqdzVd9yePB+CVdU0kz/iEZ0FnM5m2ZYj9dUtcfGlFPl5j37ikfhoNZHJoP pSHw== X-Forwarded-Encrypted: i=1; AFNElJ+B2L1WGNFRnuxDagS0h5+GCoRRCTOWB4VEz5oyDGMTzOTn6g+s7r/TjhafR9GUytt/4SAobLCrX7dyw90=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3a3cIQent7PIU8vYV/oiIjm3oazpvIVvOW7M6Oo5kojdhP0AH CatMZ/eDPcx31OUOVwXiXa8TuJ7kOrtABl1cag3J2U9pnKp3YPgClcKG X-Gm-Gg: AeBDievcwB4Kzx2ywBCacnZtJanDTrBFYatYSZDXAUh3+/jkdKdabDVFpbPQS0qrX0l zLz8l2cKlCbQGIHyfU5rE61GNYFaBNprOpfEyrU2ItFW+gQ3oINYdXIro2dUr7AFqMT7PGwnWuV b01M0Y4Jno5tY7eiEK4BkSd5uSbV27I0AFdfDj1+DfZD7ByBJ5yTslvJ16U/lSPPnFfEdb1/6cK Qcdjbx5AcOvL/OWoH9qNayhdFlm1LLdcYaS8dbRy7u94Y/a3fpP0JhKMDwJW5UxyJbDgAyIAIcS co+QbG0aF71uZSNqUkxFqo5fMu+WlW//d0vaTsXXeMP58MSl4pHmX5pF1N7te4hby1/iIdOvLfT IfrFwKE1MhnqZFRb00SKo87aOFz8cnaYLyIkRbNCMNqf8Y/4gvDBvZQE9Fx6UF1JyQQBZ+vVky/ 7jnrHaVIfl9a44MKi/8mXH2TxsfMJz X-Received: by 2002:a17:902:cec7:b0:2b2:5491:e32f with SMTP id d9443c01a7336-2b9f2579e8dmr97533225ad.16.1777901766441; Mon, 04 May 2026 06:36:06 -0700 (PDT) Received: from localhost ([111.228.63.84]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b9cae3b8e6sm99839635ad.65.2026.05.04.06.35.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2026 06:36:06 -0700 (PDT) From: Cen Zhang To: jaegeuk@kernel.org, chao@kernel.org Cc: quic_stummala@quicinc.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, Cen Zhang Subject: [PATCH v2] f2fs: start discard thread after mount recovery Date: Mon, 4 May 2026 21:35:52 +0800 Message-Id: <20260504133552.1902811-1-zzzccc427@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit create_discard_cmd_control() is called from f2fs_build_segment_manager(), before f2fs_build_node_manager() and mount recovery have completed. It currently starts the discard thread immediately, so issue_discard_thread() can run while f2fs_fill_super() is still initializing mount-time state. This is not the failure-unwind case where free_nm stops the discard thread before f2fs_destroy_node_manager() frees nm_info. The window is earlier: the thread may run while f2fs_build_node_manager() has published sbi->nm_info but init_node_manager() is still initializing it. After commit d6d2b491a82e, issue_discard_thread() may call f2fs_available_free_memory() and read fields such as nm_i->ram_thresh. The same early-start window also lets the discard thread observe the superblock read-only state while mount recovery is still making temporary SB_RDONLY transitions. Keep the discard command control available early, but start the discard thread later in f2fs_fill_super(), after node-manager initialization and mount recovery have completed. Fixes: d6d2b491a82e1e411a6766fbfb87c697d8701554 ("f2fs: allow to change discard policy based on cached discard cmds") Signed-off-by: Cen Zhang --- fs/f2fs/segment.c | 17 ++++------------- fs/f2fs/super.c | 12 ++++++++++++ 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c index 8390994a8826..deb98f564165 100644 --- a/fs/f2fs/segment.c +++ b/fs/f2fs/segment.c @@ -2302,12 +2302,10 @@ int f2fs_start_discard_thread(struct f2fs_sb_info *sbi) static int create_discard_cmd_control(struct f2fs_sb_info *sbi) { struct discard_cmd_control *dcc; - int err = 0, i; + int i; - if (SM_I(sbi)->dcc_info) { - dcc = SM_I(sbi)->dcc_info; - goto init_thread; - } + if (SM_I(sbi)->dcc_info) + return 0; dcc = f2fs_kzalloc(sbi, sizeof(struct discard_cmd_control), GFP_KERNEL); if (!dcc) @@ -2344,14 +2342,7 @@ static int create_discard_cmd_control(struct f2fs_sb_info *sbi) init_waitqueue_head(&dcc->discard_wait_queue); SM_I(sbi)->dcc_info = dcc; -init_thread: - err = f2fs_start_discard_thread(sbi); - if (err) { - kfree(dcc); - SM_I(sbi)->dcc_info = NULL; - } - - return err; + return 0; } static void destroy_discard_cmd_control(struct f2fs_sb_info *sbi) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 40079fd7886b..8228be53d036 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -5340,6 +5340,15 @@ static int f2fs_fill_super(struct super_block *sb, struct fs_context *fc) f2fs_tuning_parameters(sbi); + /* + * After POR and mount-time recovery, we can run the discard thread. It + * reads node-manager memory thresholds and the superblock read-only + * state, so keep it out of the fill_super() initialization window. + */ + err = f2fs_start_discard_thread(sbi); + if (err) + goto leave_shrinker; + f2fs_notice(sbi, "Mounted with checkpoint version = %llx", cur_cp_version(F2FS_CKPT(sbi))); f2fs_update_time(sbi, CP_TIME); @@ -5349,6 +5358,9 @@ static int f2fs_fill_super(struct super_block *sb, struct fs_context *fc) sbi->umount_lock_holder = NULL; return 0; +leave_shrinker: + f2fs_leave_shrinker(sbi); + f2fs_stop_gc_thread(sbi); sync_free_meta: /* safe to flush all the data */ sync_filesystem(sbi->sb); -- 2.43.0