The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Michal Simek <monstr@monstr.eu>
Subject: Re: [GIT PULL] ftrace: Fixes for v6.13
Date: Sun, 15 Dec 2024 16:40:34 -0500	[thread overview]
Message-ID: <20241215214034.GE2472262@mit.edu> (raw)
In-Reply-To: <CAHk-=wh5jE5ARarmYNdL4sja36_e-mnejv3zRMC62Jzn-a3omw@mail.gmail.com>

On Sun, Dec 15, 2024 at 09:23:18AM -0800, Linus Torvalds wrote:
> 
> You are literally mis-using va_list. The code is *wrong*. It depends
> on the exact calling convention of varargs, and just happens to work
> on many platforms.

It seems to me that the disagreement is fundamentally about whether we
can depend on implementation details, or the formal abstraction of
interfaces like varargs.  One school of thought is that we should only
depend on the formally defined abstraction, so that we are proof
against random breakage cauesed by compilers trying to win
benchmarketing wars by proving that they are 0.001% faster because
that makes a big deal when you can advertise on the back cover of
Businessweek.  (OK, that's really more a trick that enterprise
databases play, but you get the point.)

The other school of thought is that when trying to squeeze every last
cycle of performance (because *we* are the ones engaging in
benchmarketing wars), it's fair game to depend on implementation
details if it gets us a sufficiently large performance advantage, or
if it allows us to preserve interface semantics (perhaps for something
which was imprudently guaranteed by us when we or the code was younger
and more foolish, but we really don't want to break programs depending
on the current semantics).

I've been on both sides of this debate, although when I do the second,
it's often because I know something specific about my operating
environment (such as $WORK's data centers will *never* worry about
using big endian systems, or some such).  I *have* gotten in trouble
when I do this, so these days I insist on doumenting with big red
flags what abstractions I am violating, and the justification for
doing this, and adding tests that check to make sure that the
assumptions I am making won't suddenly break with a new version of the
compiler, or when someone tries to do something like introduce Rust
bindings, that might not know about the terrible assumptions we are
making.

I'm not convinced that it's worth it in this particular case, so I
think I side with Linus here; maybe all of this hackery isn't worth
it?  Steven, what am I missing?  Why did we go down this particular
path in the first place?  I assume there must have been something that
seemed like a good reason at the time?

						- Ted


  reply	other threads:[~2024-12-15 21:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-14 23:21 [GIT PULL] ftrace: Fixes for v6.13 Steven Rostedt
2024-12-15  0:37 ` Linus Torvalds
2024-12-15  3:04   ` Steven Rostedt
2024-12-15  3:12     ` Steven Rostedt
2024-12-15  4:06       ` Linus Torvalds
2024-12-15  4:11         ` Linus Torvalds
2024-12-15  4:38           ` Steven Rostedt
2024-12-15  5:19             ` Linus Torvalds
2024-12-15 10:05               ` Steven Rostedt
2024-12-15 10:25                 ` Steven Rostedt
2024-12-15 12:42                 ` Mathieu Desnoyers
2024-12-15 13:47                   ` Steven Rostedt
2024-12-15 14:39                     ` Mathieu Desnoyers
2024-12-15 13:51                 ` Steven Rostedt
2024-12-15 17:23                 ` Linus Torvalds
2024-12-15 21:40                   ` Theodore Ts'o [this message]
2024-12-16  1:09                     ` Steven Rostedt
2024-12-16  1:24                   ` Steven Rostedt
2024-12-16 13:33                     ` Steven Rostedt
2024-12-16 18:00                       ` Linus Torvalds
2024-12-16 17:59                     ` Linus Torvalds
2024-12-16 18:39                       ` Steven Rostedt
2024-12-15  4:00     ` Linus Torvalds
2024-12-15  4:23       ` Steven Rostedt
2024-12-15  4:37         ` Linus Torvalds
2024-12-15  4:53           ` Steven Rostedt
2024-12-15  5:20             ` Linus Torvalds
2024-12-15  4:48 ` Al Viro
2024-12-15  5:05   ` Steven Rostedt
2024-12-15  5:11     ` Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2024-12-17 16:39 Steven Rostedt
2024-12-17 17:25 ` pr-tracker-bot

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=20241215214034.GE2472262@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=monstr@monstr.eu \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox