linux-kernel - Re: [GIT PULL] tracing: Fixes for 6.6-rc2

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] [day] [month] [year] [list]

Date:   Mon, 25 Sep 2023 08:40:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Zheng Yejian <zhengyejian1@...wei.com>
Subject: Re: [GIT PULL] tracing: Fixes for 6.6-rc2

On Mon, 25 Sept 2023 at 07:53, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> These dentries and inodes are allocated for the top level directory and
> wasting memory for most users. When an instance is created it makes
> matters even worse.

So honestly, dentries are *tiny*. They are probably not any bigger
than the backing data structures you use to keep track of the names in
teh first place.

The memory cost is likely almost from the inodes, which are indeed
pretty big and fat.

> If there's a better way to achieve the same thing, I'll happily do it.

Do you actually *need* individual inodes for each of the entries in tracefd?

Because I think the *big* memory savings would be to use one single
inode for every file (make directories have individual inodes,
anything else will confuse user-space 'pwd' etc mightily)

Then you'd

 (a) have the actual tracefs-specific data in dentry->d_fsdata

 (b) use "-inode->i_op->getattr()" to make the stat() info look
different for different files (if you even care, but you might)

and I think that would be most of it.

You might hit some gotcha somewhere - things like "dcache_readdir()
will take the inode number just from the inode, and there's no
callback for it", so if you care about showing unique inode numbers to
user space, we might need to help you out some way.

But that "reuse a single inode" is actually a very traditional
pattern, even if I suspect that pattern doesn't remain anywhere. /proc
used to do things like that, iirc.

                        Linus