All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Dinh Nguyen <dinguyen@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Shuah Khan <shuah@kernel.org>
Cc: linux-kernel@vger.kernel.org, vishal.moola@gmail.com,
	akpm@linux-foundation.org, sfr@canb.auug.org.au
Subject: Re: [PATCH] Revert "nios2: Convert __pte_free_tlb() to use ptdescs"
Date: Wed, 28 Jun 2023 06:01:47 -0700	[thread overview]
Message-ID: <d83eb041-258a-c0ba-69cd-e544dda9d22f@roeck-us.net> (raw)
In-Reply-To: <cdb13c6c-9cef-905b-0ecd-94649ca075d0@roeck-us.net>

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@kernel.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.
>>
> 
> 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


  reply	other threads:[~2023-06-28 13:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 22:14 [PATCH] Revert "nios2: Convert __pte_free_tlb() to use ptdescs" Dinh Nguyen
2023-06-27 22:35 ` Linus Torvalds
2023-06-27 23:23   ` Guenter Roeck
2023-06-28 13:01     ` Guenter Roeck [this message]
2023-06-27 23:41   ` Paul E. McKenney

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=d83eb041-258a-c0ba-69cd-e544dda9d22f@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=akpm@linux-foundation.org \
    --cc=dinguyen@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=shuah@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vishal.moola@gmail.com \
    /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.