All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	 Linux Trace Devel <linux-trace-devel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	 Christian Brauner <brauner@kernel.org>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	 Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers
Date: Mon, 29 Jan 2024 10:58:30 -0800	[thread overview]
Message-ID: <CAHk-=wg8BrZEzjJ5kUyZzHPZmFqH6ooMN1gRBCofxxCfucgjaw@mail.gmail.com> (raw)
In-Reply-To: <3120f1f0-eaf8-4058-9a65-bdbee28c68c9@efficios.com>

On Mon, 29 Jan 2024 at 08:00, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> This breaks "cp -aH" and "cp -aL".

Do we care? Do we have a user that cares? Has anybody ever hit it?

Why would you ever do anything like that to tracefs filesystem?

In other words: my point is that tracefs just isn't a regular
filesystem. Never was, never will be.

And people should be *aware* of that. We should not say "hey, if it
doesn't work like a normal filesystem, it's a bug".

Try "cp -aL" on /proc, and guess what? It won't work all that well
either. For entirely *different* reasons. You'll get some variation of
"Input/output error"s, and insanely big files and quite possibly
you'll end up with recursive copying as you try to copy the file that
is /proc/self/fd/<output>.

It's just a nonsensical operation to do, and if somebody says "I can't
copy /proc on my system" it's a PEBKAC, not a kernel problem.

The "no regressions" rule is not about made-up "if I do this, behavior changes".

The "no regressions" rule is about *users*.

If you have an actual user that has been doing insane things, and we
change something, and now the insane thing no longer works, at that
point it's a regression, and we'll sigh, and go "Users are insane" and
have to fix it.

But if you have some random test that now behaves differently, it's
not a regression. It's a *warning* sign, sure: tests are useful.

So tests can show when something user-visible changed, and as such
they are a "there be monsters here" sign that maybe some user
experience will hit it too.

So I agree that "just use the same inode number" changes behavior. I
agree that it can be a bit of a danger. But these "look, I can see a
difference" isn't an argument.

And honestly, I have now spent *days* looking at tracefs, and I'm
finding core fundamental bugs that would cause actual oopses and/or
wild pointer accesses.

All of which makes me go "this code needs to be simpler and *cleaner*
and stop making problems".

In other words: tracefs is such a complete mess that I do not care one
*whit* about "cp -aL". I care about "this is actual kernel
instability".

           Linus

  reply	other threads:[~2024-01-29 18:58 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 20:02 [PATCH] eventfs: Have inodes have unique inode numbers Steven Rostedt
2024-01-26 20:25 ` Linus Torvalds
2024-01-26 21:26   ` Steven Rostedt
2024-01-26 21:31     ` Linus Torvalds
2024-01-26 21:43       ` Steven Rostedt
2024-01-26 21:36     ` Linus Torvalds
2024-01-26 21:42       ` Steven Rostedt
2024-01-26 21:49       ` Linus Torvalds
2024-01-26 22:08         ` Steven Rostedt
2024-01-26 22:26           ` Linus Torvalds
2024-01-27 14:47             ` Steven Rostedt
2024-01-28 14:42               ` Steven Rostedt
2024-01-26 22:14         ` Mathieu Desnoyers
2024-01-26 22:29           ` Linus Torvalds
2024-01-26 22:41             ` Mathieu Desnoyers
2024-01-26 22:49               ` Linus Torvalds
2024-01-29 16:00                 ` Mathieu Desnoyers
2024-01-29 18:58                   ` Linus Torvalds [this message]
2024-01-26 22:34           ` Matthew Wilcox
2024-01-26 22:40             ` Mathieu Desnoyers
2024-01-26 22:48             ` Linus Torvalds
2024-01-26 23:04               ` Matthew Wilcox
2024-01-26 23:11                 ` Linus Torvalds
2024-01-26 23:17                   ` Linus Torvalds
2024-01-27  9:36                     ` Andreas Schwab
2024-01-27 21:47         ` Linus Torvalds
2024-01-28 20:15           ` Steven Rostedt
2024-01-28 20:53             ` Linus Torvalds
2024-01-28 21:08               ` Linus Torvalds
2024-01-28 22:01                 ` Steven Rostedt
2024-01-28 22:17                   ` Linus Torvalds
2024-01-28 22:26                     ` Steven Rostedt
2024-01-28 21:11               ` Steven Rostedt
2024-01-28 21:19               ` Steven Rostedt
2024-01-28 21:43                 ` Linus Torvalds
2024-01-28 22:07                   ` Linus Torvalds
2024-01-28 22:17                     ` Steven Rostedt
2024-01-28 22:25                       ` Linus Torvalds
2024-01-28 22:51           ` Steven Rostedt
2024-01-28 23:24             ` Linus Torvalds
2024-01-28 23:59               ` Steven Rostedt
2024-01-29  0:21                 ` Steven Rostedt
2024-01-29  1:00                   ` Linus Torvalds
2024-01-29  1:42                     ` Linus Torvalds
2024-01-29  2:32                       ` Steven Rostedt
2024-01-29  3:40                         ` Steven Rostedt
2024-01-29  4:01                           ` Linus Torvalds
2024-01-29  2:09                     ` Steven Rostedt
2024-01-29  6:44                       ` Amir Goldstein
2024-01-29  9:32                         ` Steven Rostedt
2024-01-27 15:26       ` David Laight
2024-01-27 20:01         ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wg8BrZEzjJ5kUyZzHPZmFqH6ooMN1gRBCofxxCfucgjaw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=ajay.kaher@broadcom.com \
    --cc=brauner@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.