Re: linux-next: build failure after merge of the mm-hotfixes tree

[David Hildenbrand (Arm)]

>>> I'll drop this patch.
>>
>> I'll resend v2 later. Maybe we can let that rest in mm-new for 2 days to
>> get some build coverage.
> 
> OK.
> 
> I *could* start giving hotfixes a run in mm-new first, although
> 
> - it'll add a few days additional latency (which people sometimes get
>   upset about)

Yes, for some more urgent stuff we don't want that. 1 day is
probably okay, until we know the bots went crazy on it.

> 
> - haven't really seen a need for this before
> 

It happens rarely indeed.

> - coverage is mm-new is poor - for example, this error probably
>   wouldn't have been found until Mark grabbed the patch via mm-hotfixes.

I get daily build reports against mm-new, for example, mail from this night


"
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
branch HEAD: f4279f87cd6c82ebdaccdc56f38e7b80ca7fcc03  mm/vmstat: spread vmstat_update requeue across the stat interval

elapsed time: 1161m

configs tested: 157
configs skipped: 6

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig    gcc-15.2.0
alpha                            allyesconfig    gcc-15.2.0
alpha                               defconfig    gcc-15.2.0
arc                              allmodconfig    gcc-15.2.0
arc                               allnoconfig    gcc-15.2.0
arc                              allyesconfig    gcc-15.2.0
arc                                 defconfig    gcc-15.2.0
arc                   randconfig-001-20260419    gcc-12.5.0
arc                   randconfig-002-20260419    gcc-12.5.0
arm                               allnoconfig    clang-23
arm                              allyesconfig    gcc-15.2.0
arm                                 defconfig    clang-23
arm                          gemini_defconfig    clang-20
arm                   randconfig-001-20260419    gcc-8.5.0
arm                   randconfig-002-20260419    gcc-11.5.0
arm                   randconfig-003-20260419    clang-23
arm                   randconfig-004-20260419    clang-23
arm64                            allmodconfig    clang-19
arm64                             allnoconfig    gcc-15.2.0
arm64                               defconfig    gcc-15.2.0
arm64                 randconfig-001-20260419    clang-16
arm64                 randconfig-002-20260419    clang-23
arm64                 randconfig-003-20260419    clang-23
arm64                 randconfig-004-20260419    gcc-8.5.0
...
"

I suppose that was before you pushed the change? Because
I'd assume allnoconfig would have found it.

But maybe there is some more secret sauce to reproduce it.

-- 
Cheers,

David