linux-kernel - Re: [RFC PATCH 0/6] debugfs: Replace dentry with an opaque handle in debugfs API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250210122521.19cafd51@gandalf.local.home>
Date: Mon, 10 Feb 2025 12:25:21 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: David Reaver <me@...idreaver.com>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, "Rafael J . Wysocki" <rafael@...nel.org>,
 Danilo Krummrich <dakr@...nel.org>, Christian Brauner <brauner@...nel.org>,
 linux-fsdevel@...r.kernel.org, cocci@...ia.fr, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] debugfs: Replace dentry with an opaque handle
 in debugfs API

On Mon, 10 Feb 2025 12:12:46 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> From what I understand (and Christian can correct me), is that kernfs was
> created to be that interface of the "storage" connecting back to the
> kernel. Where the VFS layer deals with the user accessing the file system
> (read, write, mkdir, etc) but kernfs is the "data storage" that attaches
> those call back to the kernel to retrieve kernel information or even modify
> the kernel behavior.

To further expand on this, what a pseudo file system would need, is a way
to describe the layout of the file system, and to have the file_operations
defined for each file.

And possibly, a way to control what directories are made and what is in the
directory when a "mkdir" is performed (as mkdir in pseudo file systems
seldom create an empty directory). It would also need to handle the "rmdir"
on those directories.

Would also need to be able to store permissions too.

Debugfs did this with the dentry as the descriptor. But that dentry also
requires a static inode behind it and the memory used for all this was
really being wasted. Having a separate descriptor that acts like a storage
device and saves the file ops is basically all that is needed. It can act
like a real file system where no dentry or inode is created until the file
system is accessed by the user. And then, this descriptor can be attached
to the dentry and have an inode created for it. But after the file is no
longer referenced, the dentry and inode can be freed.

This is what is lacking with debugfs and tracefs at the moment. I did carve
out an "eventfs" from tracefs to do the above, and it saved over 20Megs in
memory when it wasn't being accessed.

-- Steve