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 E7E5C335091 for ; Mon, 3 Aug 2026 03:12:07 +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=1785726729; cv=none; b=puJxCN1yg6AHyNHqEo7PxblMktZ0+G7IFX1WVR7YTVNiq3lc5lyC8L5oQeo8W7nSxCIdA/9cYRtoDlLucR5FUqM5c/khFgZ/5a5vYbABO8VJFqveZIuOlAePCqoNaypVLG4+ULMRliGc+Uz6YC5MNOmik7buwgZxJgZgl5dZvwo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785726729; c=relaxed/simple; bh=BIVJIFE5KxbyIcYGjAqtc7cF93qI4E8Tv+wVBk02CbQ=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=FTwyusFsoVPr7/JW01NF813mtveslUyktUJLlZ+wHgZvFbtfqVnk5suAu8PblG5D4Yf3rqMkJob3accNCuO//ee/xjtJd0CHtLIurKNZDLtp1UXIcJkW2kn2IK+PwZ94XR0neSh/UcDBWAaP69Py2BfD6K8xc64aFIHaEqCpgy4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GqQKhS4q; 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="GqQKhS4q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 463B91F000E9; Mon, 3 Aug 2026 03:12:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785726727; bh=mLgTyfjp06VuzJdKqRwdfBH1RxDymkNTrq9wOfnhMGY=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=GqQKhS4qivs8koCbPh3oJxukRjZIqeUYfk2RGho/0RTFX8GCwoPjTNU0/I2NqCAid HO3RLcPsDMDigOVgr8+oiErNTHSIz9fRHAG+7K8JP8EvMmLvaq7ZD0ZsYVaDNp6JhG ngO/puoYNdUlEqDVzO4y5dJ8qYidyAWr2lbaRYtQuQLgQ0GVjWVpiHvUf3yHjz1l1S ZKJ2L97wvAKKix5VkKDKmJItDlJh/sHK0xy9/FJHeQaeXn1Lzakc9qQgfVvR31xsZb Bh6Owf2UCuJwcuzWV7qFCje6c9cEZ6y4qodKTgz1r2L8QHVuUu3KQ/qsFbPgcfqcnY wLKnkNdJ2iFXw== Message-ID: <4d421da7-aa53-4f31-81d8-c03836487f72@kernel.org> Date: Mon, 3 Aug 2026 11:12:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: chao@kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com, stable@kernel.org Subject: Re: [PATCH] f2fs: limit recovery filename logging to stored length To: Wenjie Qi , jaegeuk@kernel.org References: <20260630082331.2757376-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260630082331.2757376-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/30/26 16:23, Wenjie Qi wrote: > F2FS stores recovery filenames as a length plus a fixed-size i_name > buffer. The buffer is not NUL-terminated, but recover_inode() and > recover_dentry() print it with %s. > > For a 255-byte filename, recovery logging can read past i_name into the > following raw inode fields. > > Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN. > > Fixes: f356fe0cba0e ("f2fs: add debug msgs in the recovery routine") > Cc: stable@kernel.org > Assisted-by: Codex:gpt-5.5 > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,