Re: [PATCH v2 0/4] show orphan file inode detail info

[yebin <yebin@huaweicloud.com>]

On 2026/4/16 1:59, Jan Kara wrote:
> Hello!
>
> On Wed 15-04-26 18:55:01, Ye Bin wrote:
>> From: Ye Bin <yebin10@huawei.com>
>>
>> Diffs v2 vs v1:
>> (1) Fix sashiko review issues:
>> https://sashiko.dev/#/patchset/20260403082507.1882703-1-yebin%40huaweicloud.com
>> (2) Change "orphan_list" file mode from 0444 to 0400;
>> (3) The display format of the "orphan_list" file is modified according
>>      to Andreas' suggestions.
>> Fault injection tests have been conducted to address the issues raised
>> in the sashik review. There is no UAF issue in the ext4_seq_orphan_release()
>> function. The reason for this has already been explained in the code comments.
>> In addition to the fault injection tests, we also performed a stress test by
>> observing the /proc/fs/ext4/XX/orphan_list and the concurrent processes of
>> adding and removing orphan nodes, and no issues were found so far.
>>
>>
>> In actual production environments, the issue of inconsistency between
>> df and du is frequently encountered. In many cases, the cause of the
>> problem can be identified through the use of lsof. However, when
>> overlayfs is combined with project quota configuration, the issue becomes
>> more complex and troublesome to diagnose. First, to determine the project
>> ID, one needs to obtain orphaned nodes using `fsck.ext4 -fn /dev/xx`, and
>> then retrieve file information through `debugfs`. However, the file names
>> cannot always be obtained, and it is often unclear which files they are.
>> To identify which files these are, one would need to use crash for online
>> debugging or use kprobe to gather information incrementally. However, some
>> customers in production environments do not agree to upload any tools, and
>> online debugging might impact the business. There are also scenarios where
>> files are opened in kernel mode, which do not generate file descriptors(fds),
>> making it impossible to identify which files were deleted but still have
>> references through lsof. This patchset adds a procfs interface to query
>> information about orphaned nodes, which can assist in the analysis and
>> localization of such issues.
>
> Ye, did you read my comments to the v1 of the patchset [1]? I didn't see
> any reply from you. I don't think this is a good way how to expose orphan
> information for a filesystem for reasons I've outlined in that email.
>

Hi Jan

I thought about how to prevent resource exhaustion caused by making too many
FDs in a single application. My idea is that IOCTL should only obtain one FD
at a time, and the next time it should start obtaining orphan nodes from the
inode after the previous one. Each time an fd is obtained, the previous fd
should be closed. I expect that after traversing all the fds from the beginning,
they will all be closed and there will be no need for user space to close them
manually. I wonder if this approach is feasible? Or do you have any good
suggestions?

> 								Honza
>
> [1] https://lore.kernel.org/all/n4sccudy5avcgnkdhc27rzofzoprxqtwhfrlmsh3yyrj6vbc6d@mmu73gmtawkq/
>
>>
>> Ye Bin (4):
>>    ext4: register 'orphan_list' procfs
>>    ext4: skip cursor node in ext4_orphan_del()
>>    ext4: show inode orphan list detail information
>>    ext4: show orphan file inode detail info
>>
>>   fs/ext4/ext4.h   |   1 +
>>   fs/ext4/orphan.c | 326 ++++++++++++++++++++++++++++++++++++++++++++++-
>>   fs/ext4/sysfs.c  |   2 +
>>   3 files changed, 328 insertions(+), 1 deletion(-)
>>
>> --
>> 2.34.1
>>