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
