linux-kernel - Re: [GIT PULL] tracing: Add eventfs file to help with debugging any more issues

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: <20230915180118.4bd1cb5f@gandalf.local.home>
Date:   Fri, 15 Sep 2023 18:01:18 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ajay Kaher <akaher@...are.com>
Subject: Re: [GIT PULL] tracing: Add eventfs file to help with debugging any
 more issues

On Fri, 15 Sep 2023 14:35:40 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 15 Sept 2023 at 14:30, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > And if you really think that people need to know what the events exist
> > in eventfs, then dammit, make 'readdir()' see them. Not some stupid
> > specialty debug interface. That's what filesystems *have* readdir for.  
> 
> .. alternatively, if you have noticed that it's just a pain to not be
> able to see the data, instead of introducing this completely separate
> and illogical debug interface, just say "ok, it was a mistake, let's
> go back to just keeping things in dentries since we can _see_ those".
> 
> Put another way: this is all self-inflicted damage, and you seem to
> argue for this debug interface purely on "I can't see what's going on
> any more, the old model was really nice because you could *see* the
> events".

The entire tracing infrastructure was created because of the "I can't see
what's going on" ;-)  Not everyone is as skilled with printk as you.

The old eventfs model was too costly because of the memory footprint, which
was the entire objective of this code patch. The BPF folks told me they
looked into use a tracing instance but said it added too much memory
overhead to do so. That's when I noticed that the copy of the entire events
directory that an instance has was the culprit, and needed to be fixed.

> 
> To me, if that's really a major issue, that just says "ok, this
> eventfs abstraction was mis-designed, and hid data that the main
> developer actually wants".
> 
> We don't add new debug interfaces just because you screwed up the
> design. Fix it.

This interface is used to make sure that things are being freed, and the
overhead is low. The bugs it found was where ref counts were screwed up,
and things were permanently there or just leaked in general.

Not sure what design you want fixed.

But I get your point. I will agree that this interface will likely be
mostly useful for the first year or two after the new code is added. But
after a few years, we could delete it too. If it's a debug option I highly
doubt that any distro will keep it on and anything will actually depend on
it.

I'm not going to fight for it. I can just keep this code in patchwork that
could be easily available, or even in a git branch on my own tree.

Consider this pull request dropped.

-- Steve