Re: [PATCH] Revert "nios2: Convert __pte_free_tlb() to use ptdescs"

From: Guenter Roeck
Date: Wed Jun 28 2023 - 09:01:59 EST


On 6/27/23 16:23, Guenter Roeck wrote:
On 6/27/23 15:35, Linus Torvalds wrote:
On Tue, 27 Jun 2023 at 15:14, Dinh Nguyen <dinguyen@xxxxxxxxxx> 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.


Actually, this one is broken in linux-next as well because it was pulled
into it, but the context patches needed to make it work (compile) are not
there. It is also broken in next/pending-fixes for the same reason.

Only this happened so quick that by the time I noticed and reported
and argued that, no, I did not try to apply this patch on its own,
the pull request into mainline was already sent and applied.

Problem with linux-next is that it is so badly broken that it would take
a full-time position to track down all its failures. Then there are those
last-minute patches added in the week (or days) before the commit window
opens which break it again. This is one example, but there is at least
one more in linux-next (and pending-fixes); see
https://kerneltests.org/builders/next-sh-pending-fixes/builds/822/steps/buildcommand/logs/stdio


And now the broken (never compiled) patch made it into mainline
and breaks the sh:dreamcast_defconfig build there.

Yes, it does happen a lot that builds are temporarily broken in mainline
because patch series are split up among maintainers and submitted to mainline
without regard of buildability. I have learned to live with that and don't
normally report it because I know (ok, hope) it is going to be fixed
by the end of the commit window.

I personally find patch series - typically doing some cleanup - which are
not even build tested on the affected architectures much more annoying.

Guenter