[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4dee3069-e782-4e37-a46a-ac3a9abb82fa@redhat.com>
Date: Tue, 4 Mar 2025 11:31:27 +0100
From: David Hildenbrand <david@...hat.com>
To: Brendan Jackman <jackmanb@...gle.com>,
Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
Johannes Weiner <hannes@...xchg.org>, kernel test robot <lkp@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>, Oscar Salvador
<osalvador@...e.de>, llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
Linux Memory Management List <linux-mm@...ck.org>,
Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/page_alloc: Add lockdep assertion for pageblock type
change
On 04.03.25 11:18, Brendan Jackman wrote:
> On Tue, Mar 04, 2025 at 10:13:57AM +1100, Stephen Rothwell wrote:
>> Hi Andy,
>>
>> On Mon, 3 Mar 2025 13:18:42 +0200 Andy Shevchenko <andriy.shevchenko@...el.com> wrote:
>>>
>>> On Fri, Feb 28, 2025 at 01:28:04PM -0500, Johannes Weiner wrote:
>>>> On Sat, Mar 01, 2025 at 01:31:30AM +0800, kernel test robot wrote:
>>>
>>>> The patch is missing a dummy in_mem_hotplug() in the
>>>> !CONFIG_MEMORY_HOTPLUG section of <linux/memory_hotplug.h>.
>>>
>>> +1, I just stumbled over and this is not fixed in today's Linux Next. I'm
>>> wondering how this was missed during merge into Linux Next. Stephen?
>>
>> I just get what people put in their trees. There are no conflicts
>> around this and none of my builds failed, so I didn't see the problem.
>> Has someone sent a fix patch to Andrew? If so, if you forward it to
>> me, I will add it to linux-next today.
>
> Andrew has backed it out of mm-unstable now. There's a v2 [0] which
> still has runtime issues but AFAIK it's not in any tree yet.
>
> [0] https://lore.kernel.org/linux-mm/20250303-pageblock-lockdep-v2-1-3fc0c37e9532@google.com/
>
> In case it helps calibrate expectations: I think this particular patch
> had been reviewed but in general some patches get into mm-unstable
> without any review being recorded at all. My understanding is that
> Andrew squints at it and goes "that looks like it will probably
> eventually get merged" and puts it in so that people get a view of
> likely upcoming changes.
>
> So if an issue like this reaching linux-next is a big problem then I
> think the solution is not to merge mm-unstable. I'm not sure how
> high the bar is supposed to be for feeding into linux-next.
Last year at LSF/MM I raised that maybe we should have something
in-between mm-unstable and mm-stable that would get merged into -next. (
"mm-almost-stable" / "mm-for-next" ;) )
Alternatively, we could add something like "mm-staging" before
"mm-unstable" and "mm-stable", whereby only "mm-unstable" would get
merged into -next.
Ideally, we'd have at least build-bots and some basic sanity checks
going on on such a staging environment. After a couple of days (not
more) of survival in such an environment, it could be moved to the tree
that gets exposed to -next/
I guess the downside is that it's "yet another branch" and "yet more
build+testing" effort; in particular, if build+testing doesn't happen it
will be worthless. And likely, a lot of build+testing is happening on
linux-next only.
I have pretty good results with build bots going crazy on my branches,
so most stuff that I send (after letting is rest for a couple of days on
a public branch) doesn't really result in build issues.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists