[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgh1CDUTJD+F_utKnbW6d=wApBMC4D8hMfOs15bAn23Bg@mail.gmail.com>
Date: Tue, 27 Jun 2023 15:35:45 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dinh Nguyen <dinguyen@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Shuah Khan <shuah@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux@...ck-us.net,
vishal.moola@...il.com, akpm@...ux-foundation.org,
sfr@...b.auug.org.au
Subject: Re: [PATCH] Revert "nios2: Convert __pte_free_tlb() to use ptdescs"
On Tue, 27 Jun 2023 at 15:14, Dinh Nguyen <dinguyen@...nel.org> wrote:
>
> This reverts commit 6ebe94baa2b9ddf3ccbb7f94df6ab26234532734.
>
> The patch "nios2: Convert __pte_free_tlb() to use ptdescs" was supposed
> to go together with a patchset that Vishal Moola had planned taking it
> through the mm tree. By just having this patch, all NIOS2 builds are
> broken.
This is now at least the third time just this merge window where some
base tree was broken, and people thought that linux-next is some kind
of testing ground for it all.
NO!
Linux-next is indeed for testing, and for finding situations where
there are interactions between different trees.
But linux-next is *not* a replacement for "this tree has to work on
its own". THAT testing needs to be done independently, and *before* a
tree hits linux-next.
It is *NOT* ok to say "this will work in combination with that other
tree". EVERY SINGLE TREE needs to work on its own, because otherwise
you cannot bisect the end result sanely.
We apparently had the NIOS2 tree being broken. And the RCU tree was
broken. And the KUnit tree was broken.
In all those cases, the base tree did not compile properly on its own,
and linux-next "magically fixed" it by either having Stephen Rothwell
literally fix the build breakage by hand, or by having some other tree
hide the problem.
This is very much not ok.
I'm not sure why it happened so much this release, but this needs to
stop. People need to realize that you can't just throw shit at the
wall and see if it sticks. You need to test your own trees *first*,
and *independently* of other peoples trees.
Then, if you have done basic testing, you can then have it in
linux-next and that hopefully then finds any issues with bad
interactions with other trees, and maybe also ends up getting more
coverage testing on odd architectures and with odd configurations.
But linux-next must not in *any* way be a replacement for doing basic
testing on your own tree first.
Linus
Powered by blists - more mailing lists