linux-kernel - Re: [GIT PULL] Modules changes for v6.17-rc1

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHk-=whbY2xZpj6c-vWG0qeiDVpGa6SLA8DqqAHP2S0mu3b_pA@mail.gmail.com>
Date: Sun, 3 Aug 2025 14:38:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Daniel Gomez <da.gomez@...nel.org>
Cc: Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>, 
	Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>, 
	linux-modules@...r.kernel.org, 
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	David Gow <davidgow@...gle.com>, Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Modules changes for v6.17-rc1

On Sun, 3 Aug 2025 at 06:18, Daniel Gomez <da.gomez@...nel.org> wrote:
>
> Note that this had a conflict with sysctl changes [1] but should be fixed now as I
> rebased on top.

Christ people.

Read the documentation and *years* of me sending out emails about what
maintainers should do. Conflicts are *not* a reason to rebase.

See

   Documentation/maintainer/rebasing-and-merging.rst

and read it. Read it twice. Then read it again until you really *UNDERSTAND* it.

I deal with conflicts all the time, and that was a particularly
_trivial_ one. I'd *much* rather see a conflict and know that "yeah,
we had people working in the same area this time around" than have it
hidden by a rebase that also invalidates all the testing it got
pre-rebase.

And yes, that "invalidates all the testing" is not just some
theoretical thing. We've literally had situations where tested code
became "oops, now it doesn't work because we rebased it on top of a
tree that had different assumptions".

Is that common? No. But it's just one - of many - reasons not to
rebase, and "it had a conflict" is *NOT* a big enough reason to then
think that rebasing is better.

So "it has a conflict" is real information about the development
process, and shouldn't be hidden.

Yes, there are conflicts that are *so* painful that rebasing things is
worth it. This was not it.

And this rebase was particularly bad. You did *everything* wrong. Not
only was there not a good reason for it, you picked a starting point
that is KNOWN BUGGY AND BOOTS TO A BLACK SCREEN ON MY MACHINE. So now
your new work is basically built on top of something known broken, and
as a result, all *your*  commits are known broken too, even if that
breakage isn't due to those commits themselves.

So your rebased state is all built on a base of sand, instead of
something good and stable. And if somebody ends up having to bisect
this because of something it introduces (or even just happens to
bisect into this area for some *unrelated* reason), you picking that
random - and bad - base means that now that bisection is potentially
much more painful than it needed to be.

And yes, this is also talked about in the documentation:

  "If you must reparent a repository, do not pick some random kernel commit
   as the new base.  The kernel is often in a relatively unstable state
   between release points; basing development on one of those points
   increases the chances of running into surprising bugs.  When a patch
   series must move to a new base, pick a stable point (such as one of
   the -rc releases) to move to"

I've pulled this, because I'm flying out tomorrow, and it otherwise
looks fairly simple and straightforward.

But dammit. DO NOT MINDLESSLY REBASE YOUR TREES!

               Linus