From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3D29128E0F for ; Wed, 26 Aug 2026 00:11:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787703112; cv=none; b=e2HcOGX5EXRIxh0BUkj27WeZZZyZ/Fq1sE0szAt62UOiei69qCK2fA3biqig/KKY/wqF8aLcXWDYMtbrCaYcV1BfxIW/nOeUtoER7Qr7UVozQQgT5C33GpByVPTHWyZg/G6lMftBVWk/Yb3JYj1W+MrwsSe1LxX7VIKdmV86vrk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787703112; c=relaxed/simple; bh=+Z+8bVvj1iPk5OxPpHR3vQ4YbkoOtXd4K9HdJKeXaRo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HZNLvxGd41SAIuXjyLAkXAH74c7MJolwigdN9KwHllAKEGC9ZgDV/eJ5kUivucC7mNGWcqoJho/hRqXD14vk3NrT4p1UtoIFTeNz4ooExSsnPQBMlVnAwNjUNVQItPO+XH6JhzxwAKJn5fYGjvhoJvRTEGxW55JFW/XkBGPnfck= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N5fpd6Rf; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N5fpd6Rf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7F2B1F000E9; Wed, 26 Aug 2026 00:11:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787703110; bh=2PS5KY70aNJyYqPvv5fmig/NRtw70HPD+C2S9bEerrI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=N5fpd6Rf/upogpV5TCcxunEhA+S5ObAt1XTZvsaXFujQMe796bLGj03+5vZ53o+ol kfCOV5jrhDU8WYEjQy2p4CVCKrik93hh8+n/KRuTIJJszYawuVdy4pYVbsK/vii4I6 yqcmnt+zrAfY7V9OL+2CXbEqUSngxfLh9EkkQcTDZtp1zz9FxaaPr0sCpSUK7GY3n4 eafGgYM92ImotfYIfpl2X15IgGPpkV4Px/suGCwKj1xAyUupSlykqfMHOZkr8PjNx4 Tqh2nm3aGAARvV0/XTFARe15xFP7SkREkRGggloDWg8r8+cKehAdTdpje/K6UvOD85 HKsoo2zikrhAw== Date: Wed, 26 Aug 2026 00:11:49 +0000 From: Jaegeuk Kim To: Wenjie Qi Cc: chao@kernel.org, qiwenjie@xiaomi.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [f2fs-dev] [PATCH v3] f2fs: don't leave the hashed inode while it's unlinked Message-ID: References: <20260818200121.2684318-1-jaegeuk@kernel.org> <20260825023925.230986-1-qiwenjie@xiaomi.com> <20260825173111.1151141-1-qiwenjie@xiaomi.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260825173111.1151141-1-qiwenjie@xiaomi.com> On 08/26, Wenjie Qi wrote: > Hi Jaegeuk, > > Yes, that's true for the normal path. > > What I meant is the rollback case: err is non-zero, but __do_unlink() > may still return ret == 0. If the preceding f2fs_add_link() has already > been checkpointed, a crash before the rollback deletion is checkpointed > could expose the incomplete symlink again. Should we run f2fs_sync_fs() > for !ret && IS_DIRSYNC(dir), while preserving err? I get the point, but I feel that we don't really need to guarantee unlink, since we're going to return an error anyways? > > Regards, > Wenjie > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel