Re: [PATCH] mm/page_alloc: Add lockdep assertion for pageblock type change

[David Hildenbrand]

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@xxxxxxxxx> 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@xxxxxxxxxx/
>
> 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