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 64B303C4B92 for ; Thu, 21 May 2026 08:37:59 +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=1779352688; cv=none; b=QRhkUgDZPqGnJ3Xp4rbQba+HKT71JytfW2wDzV3x7ToPvhARpxoBLn3ddudn7rABLch1uukSgyXyoeFLIKS8kwsFB934VYYpDvjnb7gNJh4+aQSqh0PFxMdyC36k1d2kOi/w6VP0S5BEW7hQytnh+sJMIP708ePbdcoSnoyD3Ow= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779352688; c=relaxed/simple; bh=6MbWi3F1XUhMdCw20mI5DEHP8bUztRg2ZI6mr4J5bAc=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=VBAE348+U4KUIdqQcK7vTQcDHp6Pm5KYR6grdNAbcdKe4D7Jl+WsvMr9VyrukRQsUOvLIjdMLoNlbcMNxPuLa76LGBh3qnfBik+DW9mrxKIXUujKeHhEaPLmGb4K3b2D+A9tSTBK7Cw6J6Z+bdarTsJP1KbKzUpr7MM6rA8/UNQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R4e+RtM8; 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="R4e+RtM8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C9161F00ADF; Thu, 21 May 2026 08:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779352676; bh=sd5RTXvTLQ9SqMPOh7uhxmuPIMpEc4mL9L56Win7b+Y=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=R4e+RtM8yVl9oIrsU50DiXVeFGM1h0yEVW/XfmJuqtn/vPxwi6I+IXTXrIxmT4yJ9 XKbCG0NAZme4lb/y9IMUSqDinNoiOMdvwkIVSL1mDCvF3D5MTj6AMNkOxluNkyo3pq oErE4Gq3jc+2ttfsME22aee4u2629V/VNVOQ7Ava8MGycA5NyerkmJK8XzU0XGU72H aQYQ1mD5p/kh+qkoT2cptM55C0zmucGM2QcRmXomhKuqvu2q5btG3jeHuENFe7/9pV KREDdVZyyP9+5Q+k0OdofKp3wvObhjX8TGvu/RTXEOOYkjGy6fSQPUkpvhqgSUhHOG rvcy5k6styZ+g== Message-ID: Date: Thu, 21 May 2026 16:37:51 +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 Subject: Re: [PATCH] f2fs: validate compress cache inode only when enabled To: Wenjie Qi , jaegeuk@kernel.org References: <20260521031618.1734199-1-qiwenjie@xiaomi.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260521031618.1734199-1-qiwenjie@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/21/26 11:16, Wenjie Qi wrote: > F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode > number for the compressed page cache inode. That inode only exists when > the compress_cache mount option is enabled. > > When compress_cache is disabled, max_nid is outside the valid inode > range. A corrupted directory entry that points to ino == max_nid should > therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() > currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, > so f2fs_iget() bypasses do_read_inode() and its nid range check, and > instantiates a fake internal inode instead. > > Gate the compressed cache inode case on COMPRESS_CACHE, matching > f2fs_init_compress_inode(). With compress_cache disabled, ino == > max_nid now follows the normal inode path and is rejected as an > out-of-range nid. > Cc: stable@kernel.org > Fixes: 6ce19aff0b8c ("f2fs: compress: add compress_inode to cache compressed blocks") > Signed-off-by: Wenjie Qi Reviewed-by: Chao Yu Thanks,