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

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

[Mark Brown]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (arm64
allnoconfig) failed like this:

ld: Unexpected GOT/PLT entries detected!
ld: Unexpected run-time procedure linkages detected!
ld: arch/arm64/mm/fault.o: in function `tag_clear_highpages':
fault.c:(.text+0xc40): undefined reference to `mte_clear_page_tags'

Caused by commit

  99e63a49650cc (mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free)

I have used the version from next-20260420 instead.  The commit removed
the system_supports_mte() check from tag_clear_highpages() which makes
the MTE operations in the function unconditional and goes badly when MTE
is disabled in Kconfig, the system_supports_mte() check should be added
back.

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

[David Hildenbrand (Arm)]

On 4/21/26 14:59, Mark Brown wrote:
> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (arm64
> allnoconfig) failed like this:
> 
> ld: Unexpected GOT/PLT entries detected!
> ld: Unexpected run-time procedure linkages detected!
> ld: arch/arm64/mm/fault.o: in function `tag_clear_highpages':
> fault.c:(.text+0xc40): undefined reference to `mte_clear_page_tags'
> 
> Caused by commit
> 
>   99e63a49650cc (mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free)
> 

The patch will get resent (and should not have immediately been queued
in the mm-hotfixes branch).

Feel free to drop the patch on your tree.

> I have used the version from next-20260420 instead.  The commit removed
> the system_supports_mte() check from tag_clear_highpages() which makes
> the MTE operations in the function unconditional and goes badly when MTE
> is disabled in Kconfig, the system_supports_mte() check should be added
> back.

Right, or the function moved. But likely it will be added back for other
reasons.

-- 
Cheers,

David

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Tue, Apr 21, 2026 at 03:06:32PM +0200, David Hildenbrand (Arm) wrote:
> On 4/21/26 14:59, Mark Brown wrote:

> > After merging the mm-hotfixes tree, today's linux-next build (arm64
> > allnoconfig) failed like this:

> > ld: Unexpected GOT/PLT entries detected!
> > ld: Unexpected run-time procedure linkages detected!
> > ld: arch/arm64/mm/fault.o: in function `tag_clear_highpages':
> > fault.c:(.text+0xc40): undefined reference to `mte_clear_page_tags'

> > Caused by commit

> >   99e63a49650cc (mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free)

> The patch will get resent (and should not have immediately been queued
> in the mm-hotfixes branch).

> Feel free to drop the patch on your tree.

To be clear linux-next merges the trees that maintainers are publishing,
the standard fix for straight failures like this is to merge the last
version that worked.  Sometimes reverts do get applied but more usually
for things that only come up in the final builds.

> > I have used the version from next-20260420 instead.  The commit removed

The commit is also present in the mm-unstable tree, I have also used
the version of that from 20260420.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Hildenbrand (Arm)]

On 4/21/26 15:21, Mark Brown wrote:
> On Tue, Apr 21, 2026 at 03:06:32PM +0200, David Hildenbrand (Arm) wrote:
>> On 4/21/26 14:59, Mark Brown wrote:
> 
>>> After merging the mm-hotfixes tree, today's linux-next build (arm64
>>> allnoconfig) failed like this:
> 
>>> ld: Unexpected GOT/PLT entries detected!
>>> ld: Unexpected run-time procedure linkages detected!
>>> ld: arch/arm64/mm/fault.o: in function `tag_clear_highpages':
>>> fault.c:(.text+0xc40): undefined reference to `mte_clear_page_tags'
> 
>>> Caused by commit
> 
>>>   99e63a49650cc (mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free)
> 
>> The patch will get resent (and should not have immediately been queued
>> in the mm-hotfixes branch).
> 
>> Feel free to drop the patch on your tree.
> 
> To be clear linux-next merges the trees that maintainers are publishing,
> the standard fix for straight failures like this is to merge the last
> version that worked.  Sometimes reverts do get applied but more usually
> for things that only come up in the final builds.

If that unblocks you, great.

> 
>>> I have used the version from next-20260420 instead.  The commit removed
> 
> The commit is also present in the mm-unstable tree, I have also used
> the version of that from 20260420.

Yeah, it should have landed on mm-new first for 1/2 days.

-- 
Cheers,

David

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On Tue, Apr 21, 2026 at 02:21:48PM +0100, Mark Brown wrote:
> On Tue, Apr 21, 2026 at 03:06:32PM +0200, David Hildenbrand (Arm) wrote:
> > On 4/21/26 14:59, Mark Brown wrote:

> > > I have used the version from next-20260420 instead.  The commit removed
> 
> The commit is also present in the mm-unstable tree, I have also used
> the version of that from 20260420.

And similarly for the mm-nonmm-unstable tree.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Hildenbrand (Arm)]

On 4/21/26 15:34, Mark Brown wrote:
> On Tue, Apr 21, 2026 at 02:21:48PM +0100, Mark Brown wrote:
>> On Tue, Apr 21, 2026 at 03:06:32PM +0200, David Hildenbrand (Arm) wrote:
> 
>>
>> The commit is also present in the mm-unstable tree, I have also used
>> the version of that from 20260420.
> 
> And similarly for the mm-nonmm-unstable tree.

I think Andrew uses the hotfixes tree as the base for the -unstable
trees. So anything that ends up in there gets fast-tracked into -next.
Not good :(

-- 
Cheers,

David

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

[Andrew Morton]

On Tue, 21 Apr 2026 15:42:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> On 4/21/26 15:34, Mark Brown wrote:
> > On Tue, Apr 21, 2026 at 02:21:48PM +0100, Mark Brown wrote:
> >> On Tue, Apr 21, 2026 at 03:06:32PM +0200, David Hildenbrand (Arm) wrote:
> > 
> >>
> >> The commit is also present in the mm-unstable tree, I have also used
> >> the version of that from 20260420.
> > 
> > And similarly for the mm-nonmm-unstable tree.
> 
> I think Andrew uses the hotfixes tree as the base for the -unstable
> trees. So anything that ends up in there gets fast-tracked into -next.
> Not good :(

Always been this way.  The expectation is that a hotfix is small,
time-sensitive and fixes something which is broken in linux-next.  It's
exceedingly rare for a hotfix to break the build!

I'll drop this patch.

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

[David Hildenbrand (Arm)]

On 4/21/26 16:17, Andrew Morton wrote:
> On Tue, 21 Apr 2026 15:42:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> 
>> On 4/21/26 15:34, Mark Brown wrote:
>>>
>>>
>>> And similarly for the mm-nonmm-unstable tree.
>>
>> I think Andrew uses the hotfixes tree as the base for the -unstable
>> trees. So anything that ends up in there gets fast-tracked into -next.
>> Not good :(
> 
> Always been this way.  The expectation is that a hotfix is small,
> time-sensitive and fixes something which is broken in linux-next.  It's
> exceedingly rare for a hotfix to break the build!

Yeah, it's also exceedingly rare for my cross-compilations to not catch
that :(

Even the build bots did not catch that on my private github branches.

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

-- 
Cheers,

David

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

[Andrew Morton]

On Tue, 21 Apr 2026 16:20:25 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> On 4/21/26 16:17, Andrew Morton wrote:
> > On Tue, 21 Apr 2026 15:42:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > 
> >> On 4/21/26 15:34, Mark Brown wrote:
> >>>
> >>>
> >>> And similarly for the mm-nonmm-unstable tree.
> >>
> >> I think Andrew uses the hotfixes tree as the base for the -unstable
> >> trees. So anything that ends up in there gets fast-tracked into -next.
> >> Not good :(
> > 
> > Always been this way.  The expectation is that a hotfix is small,
> > time-sensitive and fixes something which is broken in linux-next.  It's
> > exceedingly rare for a hotfix to break the build!
> 
> Yeah, it's also exceedingly rare for my cross-compilations to not catch
> that :(
> 
> Even the build bots did not catch that on my private github branches.

And I'm presently away from my build machine.

> > 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)

- haven't really seen a need for this before

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

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

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

[Andrew Morton]

On Tue, 21 Apr 2026 16:35:48 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

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

OK.

> > - 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

Aren't you lucky ;).  Is it possible to add a cc:mm-commits to that script?

> I suppose that was before you pushed the change?

I think so.  I added it to mm-hotfixes

	Date: Tue, 21 Apr 2026 00:12:18 -0700

and pushed shortly after that.

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

[David Hildenbrand (Arm)]

> 
>>> - 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
> 
> Aren't you lucky ;).  Is it possible to add a cc:mm-commits to that script?
> 

Hehe, if it finds something that is broken, it sends mails to the list
like [1]

I only get the build summaries. While we were testing the 0day
integration of mm-new, we tried to keep the noise for other to a minimum.

@Phil, could we also Cc mm-commits@vger.kernel.org and Andrew on the
build summaries for mm-new, like the one from yesterday:

"[akpm-mm:mm-new] BUILD SUCCESS f4279f87cd6c82ebdaccdc56f38e7b80ca7fcc03"

Thanks!

[1] https://lore.kernel.org/all/202604171841.MGvqbmu8-lkp@intel.com/

-- 
Cheers,

David

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

[Philip Li]

On Tue, Apr 21, 2026 at 05:04:55PM +0200, David Hildenbrand (Arm) wrote:
> > 
> >>> - 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
> > 
> > Aren't you lucky ;).  Is it possible to add a cc:mm-commits to that script?
> > 
> 
> Hehe, if it finds something that is broken, it sends mails to the list
> like [1]
> 
> I only get the build summaries. While we were testing the 0day
> integration of mm-new, we tried to keep the noise for other to a minimum.
> 
> @Phil, could we also Cc mm-commits@vger.kernel.org and Andrew on the
> build summaries for mm-new, like the one from yesterday:

Got it, I will configure the bot to add cc for mm-commits@vger.kernel.org and
Andrew.

> 
> "[akpm-mm:mm-new] BUILD SUCCESS f4279f87cd6c82ebdaccdc56f38e7b80ca7fcc03"
> 
> Thanks!
> 
> [1] https://lore.kernel.org/all/202604171841.MGvqbmu8-lkp@intel.com/
> 
> -- 
> Cheers,
> 
> David

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

[David Hildenbrand (Arm)]

On 4/21/26 18:04, Philip Li wrote:
> On Tue, Apr 21, 2026 at 05:04:55PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>>
>>> Aren't you lucky ;).  Is it possible to add a cc:mm-commits to that script?
>>>
>>
>> Hehe, if it finds something that is broken, it sends mails to the list
>> like [1]
>>
>> I only get the build summaries. While we were testing the 0day
>> integration of mm-new, we tried to keep the noise for other to a minimum.
>>
>> @Phil, could we also Cc mm-commits@vger.kernel.org and Andrew on the
>> build summaries for mm-new, like the one from yesterday:
> 
> Got it, I will configure the bot to add cc for mm-commits@vger.kernel.org and
> Andrew.

Awesome, thanks!

-- 
Cheers,

David

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Tue, Apr 21, 2026 at 07:17:01AM -0700, Andrew Morton wrote:
> On Tue, 21 Apr 2026 15:42:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > On 4/21/26 15:34, Mark Brown wrote:
> > > On Tue, Apr 21, 2026 at 02:21:48PM +0100, Mark Brown wrote:

> > > And similarly for the mm-nonmm-unstable tree.

> > I think Andrew uses the hotfixes tree as the base for the -unstable
> > trees. So anything that ends up in there gets fast-tracked into -next.
> > Not good :(

> Always been this way.  The expectation is that a hotfix is small,
> time-sensitive and fixes something which is broken in linux-next.  It's
> exceedingly rare for a hotfix to break the build!

> I'll drop this patch.

Thanks.  David, to be clear none of this is much more than a minor
annoyance - I'm just reporting all the trees I'm holding back so there's
a paper trail for anyone who goes looking to figure out why that's been
done.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[David Hildenbrand (Arm)]

On 4/21/26 16:28, Mark Brown wrote:
> On Tue, Apr 21, 2026 at 07:17:01AM -0700, Andrew Morton wrote:
>> On Tue, 21 Apr 2026 15:42:29 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> 
> 
>>> I think Andrew uses the hotfixes tree as the base for the -unstable
>>> trees. So anything that ends up in there gets fast-tracked into -next.
>>> Not good :(
> 
>> Always been this way.  The expectation is that a hotfix is small,
>> time-sensitive and fixes something which is broken in linux-next.  It's
>> exceedingly rare for a hotfix to break the build!
> 
>> I'll drop this patch.
> 
> Thanks.  David, to be clear none of this is much more than a minor
> annoyance

Right, and I want you to have as little such annoyances as possible :)

-- 
Cheers,

David

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from arch/x86/include/asm/bug.h:193,
                 from include/linux/bug.h:5,
                 from include/linux/kasan.h:5,
                 from mm/kasan/common.c:14:
mm/kasan/common.c: In function '__kasan_unpoison_vmap_areas':
mm/kasan/common.c:594:34: error: 'KASAN_VMALLOC_KEEP_TAG' undeclared (first use in this function); did you mean 'KASAN_VMALLOC_PAGE_RANGE'?
  594 |         if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG))
      |                                  ^~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:120:32: note: in definition of macro 'WARN_ON_ONCE'
  120 |         int __ret_warn_on = !!(condition);                              \
      |                                ^~~~~~~~~
mm/kasan/common.c:594:34: note: each undeclared identifier is reported only once for each function it appears in
  594 |         if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG))
      |                                  ^~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/bug.h:120:32: note: in definition of macro 'WARN_ON_ONCE'
  120 |         int __ret_warn_on = !!(condition);                              \
      |                                ^~~~~~~~~

Caused by commit

  6b83afdcfa93 ("kasan: unpoison vms[area] addresses with a common tag")

I have reverted that commit (and the following 2 fixes) for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Maciej Wieczor-Retman]

Hi!

This flag, KASAN_VMALLOC_KEEP_TAG was defined in the first patch by Jiayuan in
my three piece series [1]. I looked over git logs in mm-unstable and
mm-hotfixes-unstable and I guess it wasn't pulled there but my two following
patches were.

Could you pull the [1] missing patch Andrew? I think that should fix this issue.
Thanks :)

[1] https://lore.kernel.org/all/247fd641cbf4a8e6c8135051772867f6bd2610ad.1764945396.git.m.wieczorretman@pm.me/

kind regards
Maciej Wieczór-Retman

On 2025-12-08 at 08:35:11 +1100, Stephen Rothwell wrote:
>Hi all,
>
>After merging the mm-hotfixes tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>In file included from arch/x86/include/asm/bug.h:193,
>                 from include/linux/bug.h:5,
>                 from include/linux/kasan.h:5,
>                 from mm/kasan/common.c:14:
>mm/kasan/common.c: In function '__kasan_unpoison_vmap_areas':
>mm/kasan/common.c:594:34: error: 'KASAN_VMALLOC_KEEP_TAG' undeclared (first use in this function); did you mean 'KASAN_VMALLOC_PAGE_RANGE'?
>  594 |         if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG))
>      |                                  ^~~~~~~~~~~~~~~~~~~~~~
>include/asm-generic/bug.h:120:32: note: in definition of macro 'WARN_ON_ONCE'
>  120 |         int __ret_warn_on = !!(condition);                              \
>      |                                ^~~~~~~~~
>mm/kasan/common.c:594:34: note: each undeclared identifier is reported only once for each function it appears in
>  594 |         if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG))
>      |                                  ^~~~~~~~~~~~~~~~~~~~~~
>include/asm-generic/bug.h:120:32: note: in definition of macro 'WARN_ON_ONCE'
>  120 |         int __ret_warn_on = !!(condition);                              \
>      |                                ^~~~~~~~~
>
>Caused by commit
>
>  6b83afdcfa93 ("kasan: unpoison vms[area] addresses with a common tag")
>
>I have reverted that commit (and the following 2 fixes) for today.
>
>-- 
>Cheers,
>Stephen Rothwell

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

[Andrew Morton]

On Mon, 8 Dec 2025 11:30:16 +0100 Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> wrote:

> This flag, KASAN_VMALLOC_KEEP_TAG was defined in the first patch by Jiayuan in
> my three piece series [1]. I looked over git logs in mm-unstable and
> mm-hotfixes-unstable and I guess it wasn't pulled there but my two following
> patches were.
> 
> Could you pull the [1] missing patch Andrew? I think that should fix this issue.
> Thanks :)
> 
> [1] https://lore.kernel.org/all/247fd641cbf4a8e6c8135051772867f6bd2610ad.1764945396.git.m.wieczorretman@pm.me/

thanks, yup, restored.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 399 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (powerpc
allyesconfig) failed like this:

ld: mm/kasan/init.o:(.toc+0x0): undefined reference to `kasan_early_shadow_p4d'

Caused by commit

  4b99d7a3e69a ("mm: introduce and use {pgd,p4d}_populate_kernel()")

I have reverted that commit (and the following 07cf1bc1f659) for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Harry Yoo]

On Thu, Aug 21, 2025 at 04:05:15PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> ld: mm/kasan/init.o:(.toc+0x0): undefined reference to `kasan_early_shadow_p4d'
> 
> Caused by commit
> 
>   4b99d7a3e69a ("mm: introduce and use {pgd,p4d}_populate_kernel()")
> 
> I have reverted that commit (and the following 07cf1bc1f659) for today.

Hi Stephen, thanks for reporting the build error.
I've sent a fix for it [1], and hopefully we can add it to mm-hotfixes soon.

[1] https://lore.kernel.org/linux-mm/20250821093542.37844-1-harry.yoo@oracle.com

-- 
Cheers,
Harry / Hyeonggon

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

mm/khugepaged.c: In function 'hpage_collapse_scan_file':
mm/khugepaged.c:2337:21: error: implicit declaration of function 'folio_expected_ref_count' [-Wimplicit-function-declaration]
 2337 |                 if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~

Caused by commit

  3bdddbba5f02 ("mm/khugepaged: fix race with folio split/free using temporary reference")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Andrew Morton]

On Thu, 29 May 2025 09:59:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/khugepaged.c: In function 'hpage_collapse_scan_file':
> mm/khugepaged.c:2337:21: error: implicit declaration of function 'folio_expected_ref_count' [-Wimplicit-function-declaration]
>  2337 |                 if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
>       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   3bdddbba5f02 ("mm/khugepaged: fix race with folio split/free using temporary reference")
> 
> I have reverted that commit for today.

yup, thanks, that was dependent on an mm-stable patch!  I have
reordered things to plug the bisection hole.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Hi Andrew,

On Wed, 28 May 2025 17:02:56 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 29 May 2025 09:59:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the mm-hotfixes tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > mm/khugepaged.c: In function 'hpage_collapse_scan_file':
> > mm/khugepaged.c:2337:21: error: implicit declaration of function 'folio_expected_ref_count' [-Wimplicit-function-declaration]
> >  2337 |                 if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
> >       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Caused by commit
> > 
> >   3bdddbba5f02 ("mm/khugepaged: fix race with folio split/free using temporary reference")
> > 
> > I have reverted that commit for today.  
> 
> yup, thanks, that was dependent on an mm-stable patch!  I have
> reordered things to plug the bisection hole.

Snap!

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Hi all,

On Thu, 29 May 2025 09:59:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> 
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/khugepaged.c: In function 'hpage_collapse_scan_file':
> mm/khugepaged.c:2337:21: error: implicit declaration of function 'folio_expected_ref_count' [-Wimplicit-function-declaration]
>  2337 |                 if (folio_expected_ref_count(folio) + 1 != folio_ref_count(folio)) {
>       |                     ^~~~~~~~~~~~~~~~~~~~~~~~
> 
> Caused by commit
> 
>   3bdddbba5f02 ("mm/khugepaged: fix race with folio split/free using temporary reference")
> 
> I have reverted that commit for today.

folio_expected_ref_count() is not introduced until commit

  86ebd50224c0 ("mm: add folio_expected_ref_count() for reference count calculation")

in the mm-stable tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

mm/gup.c: In function 'gup_hugepte':
mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
  474 |                 folio = try_grab_folio_fast(page, refs, flags);
      |                         ^~~~~~~~~~~~~~~~~~~
      |                         try_grab_folio
mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  474 |                 folio = try_grab_folio_fast(page, refs, flags);
      |                       ^
mm/gup.c: At top level:
mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
 2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
      |                      ^~~~~~~~~~~~~~~~~~~
mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
  474 |                 folio = try_grab_folio_fast(page, refs, flags);
      |                         ^~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

Caused by commit

  5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Hi all,

On Mon, 1 Jul 2024 10:16:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> mm/gup.c: In function 'gup_hugepte':
> mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
>   474 |                 folio = try_grab_folio_fast(page, refs, flags);
>       |                         ^~~~~~~~~~~~~~~~~~~
>       |                         try_grab_folio
> mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>   474 |                 folio = try_grab_folio_fast(page, refs, flags);
>       |                       ^
> mm/gup.c: At top level:
> mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
>  2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
>       |                      ^~~~~~~~~~~~~~~~~~~
> mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
>   474 |                 folio = try_grab_folio_fast(page, refs, flags);
>       |                         ^~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> 
> Caused by commit
> 
>   5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")
> 
> I have reverted that commit for today.

And I also had to revert commit

  52cca85b0ebf ("mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix")

from the mm-unstable branch of the mm tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Yang Shi]

On 6/30/24 6:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 1 Jul 2024 10:16:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> After merging the mm-hotfixes tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> mm/gup.c: In function 'gup_hugepte':
>> mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
>>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>        |                         ^~~~~~~~~~~~~~~~~~~
>>        |                         try_grab_folio
>> mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>        |                       ^
>> mm/gup.c: At top level:
>> mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
>>   2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
>>        |                      ^~~~~~~~~~~~~~~~~~~
>> mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
>>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>        |                         ^~~~~~~~~~~~~~~~~~~
>> cc1: some warnings being treated as errors
>>
>> Caused by commit
>>
>>    5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")
>>
>> I have reverted that commit for today.
> And I also had to revert commit
>
>    52cca85b0ebf ("mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix")
>
> from the mm-unstable branch of the mm tree.

The patch attached in this mail should fix the compile error.

https://lore.kernel.org/linux-mm/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com/

>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]

Hi Andrew,

On Mon, 1 Jul 2024 11:15:17 -0700 Yang Shi <yang@os.amperecomputing.com> wrote:
>
> On 6/30/24 6:01 PM, Stephen Rothwell wrote:
> >
> > On Mon, 1 Jul 2024 10:16:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> >> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> >> ppc64_defconfig) failed like this:
> >>
> >> mm/gup.c: In function 'gup_hugepte':
> >> mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
> >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> >>        |                         ^~~~~~~~~~~~~~~~~~~
> >>        |                         try_grab_folio
> >> mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> >>        |                       ^
> >> mm/gup.c: At top level:
> >> mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
> >>   2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
> >>        |                      ^~~~~~~~~~~~~~~~~~~
> >> mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
> >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> >>        |                         ^~~~~~~~~~~~~~~~~~~
> >> cc1: some warnings being treated as errors
> >>
> >> Caused by commit
> >>
> >>    5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")
> >>
> >> I have reverted that commit for today.  
> > And I also had to revert commit
> >
> >    52cca85b0ebf ("mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix")
> >
> > from the mm-unstable branch of the mm tree.  
> 
> The patch attached in this mail should fix the compile error.
> 
> https://lore.kernel.org/linux-mm/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com/

It looks like that patch has been applied to the mm tree instead of the
mm-hotfixes tree - as a fix for commit

  50ceb37037f3 ("mm: gup: stop abusing try_grab_folio")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]

Hi Andrew,

On Wed, 3 Jul 2024 08:44:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 1 Jul 2024 11:15:17 -0700 Yang Shi <yang@os.amperecomputing.com> wrote:
> >
> > On 6/30/24 6:01 PM, Stephen Rothwell wrote:  
> > >
> > > On Mon, 1 Jul 2024 10:16:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:    
> > >> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) failed like this:
> > >>
> > >> mm/gup.c: In function 'gup_hugepte':
> > >> mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
> > >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> > >>        |                         ^~~~~~~~~~~~~~~~~~~
> > >>        |                         try_grab_folio
> > >> mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> > >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> > >>        |                       ^
> > >> mm/gup.c: At top level:
> > >> mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
> > >>   2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
> > >>        |                      ^~~~~~~~~~~~~~~~~~~
> > >> mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
> > >>    474 |                 folio = try_grab_folio_fast(page, refs, flags);
> > >>        |                         ^~~~~~~~~~~~~~~~~~~
> > >> cc1: some warnings being treated as errors
> > >>
> > >> Caused by commit
> > >>
> > >>    5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")
> > >>
> > >> I have reverted that commit for today.    
> > > And I also had to revert commit
> > >
> > >    52cca85b0ebf ("mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix")
> > >
> > > from the mm-unstable branch of the mm tree.    
> > 
> > The patch attached in this mail should fix the compile error.
> > 
> > https://lore.kernel.org/linux-mm/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com/  
> 
> It looks like that patch has been applied to the mm tree instead of the
> mm-hotfixes tree - as a fix for commit
> 
>   50ceb37037f3 ("mm: gup: stop abusing try_grab_folio")

So for today, I have applied the following patch to the mm-hotfixes
tree merge and stopped reverting
mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Jul 2024 08:52:20 +1000
Subject: [PATCH] fixup for "mm: gup: stop abusing try_grab_folio"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 mm/gup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/gup.c b/mm/gup.c
index 12c7b41712f7..5f58c95b3ab9 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -437,6 +437,9 @@ static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
 	return (__boundary - 1 < end - 1) ? __boundary : end;
 }
 
+static struct folio *try_grab_folio_fast(struct page *page, int refs,
+					 unsigned int flags);
+
 /*
  * Returns 1 if succeeded, 0 if failed, -EMLINK if unshare needed.
  *
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Yang Shi]

On 7/2/24 4:22 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> On Wed, 3 Jul 2024 08:44:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Mon, 1 Jul 2024 11:15:17 -0700 Yang Shi <yang@os.amperecomputing.com> wrote:
>>> On 6/30/24 6:01 PM, Stephen Rothwell wrote:
>>>> On Mon, 1 Jul 2024 10:16:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>>> After merging the mm-hotfixes tree, today's linux-next build (powerpc
>>>>> ppc64_defconfig) failed like this:
>>>>>
>>>>> mm/gup.c: In function 'gup_hugepte':
>>>>> mm/gup.c:474:25: error: implicit declaration of function 'try_grab_folio_fast'; did you mean 'try_grab_folio'? [-Werror=implicit-function-declaration]
>>>>>     474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>>>>         |                         ^~~~~~~~~~~~~~~~~~~
>>>>>         |                         try_grab_folio
>>>>> mm/gup.c:474:23: warning: assignment to 'struct folio *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
>>>>>     474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>>>>         |                       ^
>>>>> mm/gup.c: At top level:
>>>>> mm/gup.c:2747:22: error: conflicting types for 'try_grab_folio_fast'; have 'struct folio *(struct page *, int,  unsigned int)'
>>>>>    2747 | static struct folio *try_grab_folio_fast(struct page *page, int refs,
>>>>>         |                      ^~~~~~~~~~~~~~~~~~~
>>>>> mm/gup.c:474:25: note: previous implicit declaration of 'try_grab_folio_fast' with type 'int()'
>>>>>     474 |                 folio = try_grab_folio_fast(page, refs, flags);
>>>>>         |                         ^~~~~~~~~~~~~~~~~~~
>>>>> cc1: some warnings being treated as errors
>>>>>
>>>>> Caused by commit
>>>>>
>>>>>     5f408bfe0d13 ("mm: gup: stop abusing try_grab_folio")
>>>>>
>>>>> I have reverted that commit for today.
>>>> And I also had to revert commit
>>>>
>>>>     52cca85b0ebf ("mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix")
>>>>
>>>> from the mm-unstable branch of the mm tree.
>>> The patch attached in this mail should fix the compile error.
>>>
>>> https://lore.kernel.org/linux-mm/CAHbLzkowMSso-4Nufc9hcMehQsK9PNz3OSu-+eniU-2Mm-xjhA@mail.gmail.com/
>> It looks like that patch has been applied to the mm tree instead of the
>> mm-hotfixes tree - as a fix for commit
>>
>>    50ceb37037f3 ("mm: gup: stop abusing try_grab_folio")
> So for today, I have applied the following patch to the mm-hotfixes
> tree merge and stopped reverting
> mm-gup-introduce-memfd_pin_folios-for-pinning-memfd-folios-fix.

Thanks, Stephen. I think Andrew may misread what my patch fixed. I 
emailed him offline. Once he fixed it you should not need this 
workaround anymore.

>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 3 Jul 2024 08:52:20 +1000
> Subject: [PATCH] fixup for "mm: gup: stop abusing try_grab_folio"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>   mm/gup.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 12c7b41712f7..5f58c95b3ab9 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -437,6 +437,9 @@ static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
>   	return (__boundary - 1 < end - 1) ? __boundary : end;
>   }
>   
> +static struct folio *try_grab_folio_fast(struct page *page, int refs,
> +					 unsigned int flags);
> +
>   /*
>    * Returns 1 if succeeded, 0 if failed, -EMLINK if unshare needed.
>    *

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

lib/maple_tree.c: In function 'mas_preallocate':
lib/maple_tree.c:5506:30: error: 'struct ma_state' has no member named 'end'
 5506 |         if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree))
      |                              ^~

Caused by commit

  84bda0b24555 ("maple_tree: do not preallocate nodes for slot stores")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Liam R. Howlett]

* Stephen Rothwell <sfr@canb.auug.org.au> [231213 17:18]:
> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> lib/maple_tree.c: In function 'mas_preallocate':
> lib/maple_tree.c:5506:30: error: 'struct ma_state' has no member named 'end'
>  5506 |         if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree))
>       |                              ^~
> 
> Caused by commit
> 
>   84bda0b24555 ("maple_tree: do not preallocate nodes for slot stores")
> 
> I have reverted that commit for today.


No harm in leaving it, but akpm made a 'fixlet' for this [1].  The word
fixlet made my day.  I assume this will be fix(let)ed tomorrow.

Cheers,
Liam

[1] https://lore.kernel.org/linux-mm/20231213130923.cc00317b4ebab1b0864d8b42@linux-foundation.org/

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

mm/ksm.c: In function 'ksm_might_need_to_copy':
mm/ksm.c:2605:21: error: implicit declaration of function 'copy_mc_user_highpage'; did you mean 'copy_user_highpage'? [-Werror=implicit-function-declaration]
 2605 |                 if (copy_mc_user_highpage(new_page, page, address, vma)) {
      |                     ^~~~~~~~~~~~~~~~~~~~~
      |                     copy_user_highpage

Caused by commit

  b7edf4b1cdb1 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Kefeng Wang]

Hi, this patch relays on Tony Luck's Patch series "Copy-on-write poison 
recovery".[1]
and tested ppc64_defconfig based on next-20221208, it's no build failure

I think it is not very hotfix, also will send v3 to address some comments
we could adjust the patch order in mm tree, thanks.

[1] 
https://lore.kernel.org/all/50506c8a-71c1-9c68-aa47-7e8dc68a3c52@huawei.com/ 



On 2022/12/13 6:30, Stephen Rothwell wrote:
> Hi all,
>
> After merging the mm-hotfixes tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/ksm.c: In function 'ksm_might_need_to_copy':
> mm/ksm.c:2605:21: error: implicit declaration of function 'copy_mc_user_highpage'; did you mean 'copy_user_highpage'? [-Werror=implicit-function-declaration]
>   2605 |                 if (copy_mc_user_highpage(new_page, page, address, vma)) {
>        |                     ^~~~~~~~~~~~~~~~~~~~~
>        |                     copy_user_highpage
>
> Caused by commit
>
>    b7edf4b1cdb1 ("mm: hwpoison: support recovery from ksm_might_need_to_copy()")
>
> I have reverted that commit for today.
>

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

[Andrew Morton]

On Tue, 13 Dec 2022 09:34:24 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote:

> Hi, this patch relays on Tony Luck's Patch series "Copy-on-write poison 
> recovery".[1]
> and tested ppc64_defconfig based on next-20221208, it's no build failure

I reordered these a couple of days ago, not sure how Stephen got a hold
of this tree - perhaps I wasn't pushy enough.

Stephen, quoting the mm-everything tag would be helpful, but rarely
useful so only if you're feeling bored ;)

> I think it is not very hotfix, also will send v3 to address some comments
> we could adjust the patch order in mm tree, thanks.

This patch is still in mm-unstable so updates won't be a problem. 
Soon, please.

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Hi Andrew,

On Mon, 12 Dec 2022 18:23:04 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 13 Dec 2022 09:34:24 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
> 
> > Hi, this patch relays on Tony Luck's Patch series "Copy-on-write poison 
> > recovery".[1]
> > and tested ppc64_defconfig based on next-20221208, it's no build failure  
> 
> I reordered these a couple of days ago, not sure how Stephen got a hold
> of this tree - perhaps I wasn't pushy enough.

Probably, its just what I got when I fetched your branches this morning
(my time).

> Stephen, quoting the mm-everything tag would be helpful, but rarely
> useful so only if you're feeling bored ;)

OK, I will try to remember.

Part of the problem (for me) is that you sometimes update all your
branches in the middle of my day (I am not asking you to stop doing
that - I can cope), so the mm-hotifxes that I have merged early on does
not match the new mm-hotfixes-* branches that get merged as part of mm
(mm-everything) later in the day.  This occasionally causes conflicts,
but they are invariably trivial and fixed by using the versions of
files from the new branches.  I am wondering if maybe I should merge
mm-everything early (but after I have merged and tested all the -fixes
branches) to narrow the race condition :-)

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Kefeng Wang]

On 2022/12/13 10:23, Andrew Morton wrote:
> On Tue, 13 Dec 2022 09:34:24 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
>> Hi, this patch relays on Tony Luck's Patch series "Copy-on-write poison
>> recovery".[1]
>> and tested ppc64_defconfig based on next-20221208, it's no build failure
...
>> I think it is not very hotfix, also will send v3 to address some comments
>> we could adjust the patch order in mm tree, thanks.
> This patch is still in mm-unstable so updates won't be a problem.
> Soon, please.
Done, thanks.
>

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

Hi all,

After merging the mm-hotfixes tree, today's linux-next build (arm
allmodconfig) failed like this:

mm/vmscan.c:4090:9: error: implicit declaration of function ‘pmd_young’; did you mean ‘pte_young’? [-Werror=implicit-function-declaration]

Caused by commit

  3f85e711d5af ("mm: introduce arch_has_hw_nonleaf_pmd_young()")

This error was found by the kernel.ci bot and so is still int today's
tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 492 bytes --]

On 25.11.22 02:10, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (arm
> allmodconfig) failed like this:
> 
> mm/vmscan.c:4090:9: error: implicit declaration of function ‘pmd_young’; did you mean ‘pte_young’? [-Werror=implicit-function-declaration]
> 
> Caused by commit
> 
>    3f85e711d5af ("mm: introduce arch_has_hw_nonleaf_pmd_young()")

A patch fixing this is available already (see attached mail).


Juergen

[-- Attachment #1.1.2: + mm-add-dummy-pmd_young-for-architectures-not-having-it.patch added to mm-hotfixes-unstable branch.eml --]
[-- Type: message/rfc822, Size: 14689 bytes --]

From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,yuzhao@google.com,tglx@linutronix.de,mingo@redhat.com,linux@eikelenboom.it,hpa@zytor.com,geert@linux-m68k.org,dave.hansen@linux.intel.com,bp@alien8.de,jgross@suse.com,akpm@linux-foundation.org
Subject: + mm-add-dummy-pmd_young-for-architectures-not-having-it.patch added to mm-hotfixes-unstable branch
Date: Thu, 24 Nov 2022 13:35:01 -0800
Message-ID: <20221124213502.78CF4C433D6@smtp.kernel.org>


The patch titled
     Subject: mm: add dummy pmd_young() for architectures not having it
has been added to the -mm mm-hotfixes-unstable branch.  Its filename is
     mm-add-dummy-pmd_young-for-architectures-not-having-it.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-add-dummy-pmd_young-for-architectures-not-having-it.patch

This patch will later appear in the mm-hotfixes-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days

------------------------------------------------------
From: Juergen Gross <jgross@suse.com>
Subject: mm: add dummy pmd_young() for architectures not having it

In order to avoid #ifdeffery add a dummy pmd_young() implementation as a
fallback.  This is required for the later patch "mm: introduce
arch_has_hw_nonleaf_pmd_young()".

Link: https://lkml.kernel.org/r/fd3ac3cd-7349-6bbd-890a-71a9454ca0b3@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/loongarch/include/asm/pgtable.h |    1 +
 arch/mips/include/asm/pgtable.h      |    1 +
 arch/riscv/include/asm/pgtable.h     |    1 +
 arch/s390/include/asm/pgtable.h      |    1 +
 arch/sparc/include/asm/pgtable_64.h  |    1 +
 arch/x86/include/asm/pgtable.h       |    1 +
 include/linux/pgtable.h              |    7 +++++++
 7 files changed, 13 insertions(+)

--- a/arch/loongarch/include/asm/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/loongarch/include/asm/pgtable.h
@@ -482,6 +482,7 @@ static inline pmd_t pmd_mkdirty(pmd_t pm
 	return pmd;
 }
 
+#define pmd_young pmd_young
 static inline int pmd_young(pmd_t pmd)
 {
 	return !!(pmd_val(pmd) & _PAGE_ACCESSED);
--- a/arch/mips/include/asm/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/mips/include/asm/pgtable.h
@@ -622,6 +622,7 @@ static inline pmd_t pmd_mkdirty(pmd_t pm
 	return pmd;
 }
 
+#define pmd_young pmd_young
 static inline int pmd_young(pmd_t pmd)
 {
 	return !!(pmd_val(pmd) & _PAGE_ACCESSED);
--- a/arch/riscv/include/asm/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/riscv/include/asm/pgtable.h
@@ -600,6 +600,7 @@ static inline int pmd_dirty(pmd_t pmd)
 	return pte_dirty(pmd_pte(pmd));
 }
 
+#define pmd_young pmd_young
 static inline int pmd_young(pmd_t pmd)
 {
 	return pte_young(pmd_pte(pmd));
--- a/arch/s390/include/asm/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/s390/include/asm/pgtable.h
@@ -763,6 +763,7 @@ static inline int pmd_dirty(pmd_t pmd)
 	return (pmd_val(pmd) & _SEGMENT_ENTRY_DIRTY) != 0;
 }
 
+#define pmd_young pmd_young
 static inline int pmd_young(pmd_t pmd)
 {
 	return (pmd_val(pmd) & _SEGMENT_ENTRY_YOUNG) != 0;
--- a/arch/sparc/include/asm/pgtable_64.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/sparc/include/asm/pgtable_64.h
@@ -693,6 +693,7 @@ static inline unsigned long pmd_dirty(pm
 	return pte_dirty(pte);
 }
 
+#define pmd_young pmd_young
 static inline unsigned long pmd_young(pmd_t pmd)
 {
 	pte_t pte = __pte(pmd_val(pmd));
--- a/arch/x86/include/asm/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/arch/x86/include/asm/pgtable.h
@@ -139,6 +139,7 @@ static inline int pmd_dirty(pmd_t pmd)
 	return pmd_flags(pmd) & _PAGE_DIRTY;
 }
 
+#define pmd_young pmd_young
 static inline int pmd_young(pmd_t pmd)
 {
 	return pmd_flags(pmd) & _PAGE_ACCESSED;
--- a/include/linux/pgtable.h~mm-add-dummy-pmd_young-for-architectures-not-having-it
+++ a/include/linux/pgtable.h
@@ -165,6 +165,13 @@ static inline pte_t *virt_to_kpte(unsign
 	return pmd_none(*pmd) ? NULL : pte_offset_kernel(pmd, vaddr);
 }
 
+#ifndef pmd_young
+static inline int pmd_young(pmd_t pmd)
+{
+	return 0;
+}
+#endif
+
 #ifndef __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
 extern int ptep_set_access_flags(struct vm_area_struct *vma,
 				 unsigned long address, pte_t *ptep,
_

Patches currently in -mm which might be from jgross@suse.com are

mm-add-dummy-pmd_young-for-architectures-not-having-it.patch
mm-introduce-arch_has_hw_nonleaf_pmd_young.patch

[-- Attachment #1.1.3: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

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

[Andrew Morton]

On Fri, 25 Nov 2022 12:10:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the mm-hotfixes tree, today's linux-next build (arm
> allmodconfig) failed like this:
> 
> mm/vmscan.c:4090:9: error: implicit declaration of function ‘pmd_young’; did you mean ‘pte_young’? [-Werror=implicit-function-declaration]
> 
> Caused by commit
> 
>   3f85e711d5af ("mm: introduce arch_has_hw_nonleaf_pmd_young()")
> 
> This error was found by the kernel.ci bot and so is still int today's
> tree.

Thanks.  Did that tree include "mm: add dummy pmd_young() for
architectures not having it"?

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Hi Andrew,

On Thu, 24 Nov 2022 21:24:57 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 25 Nov 2022 12:10:51 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > After merging the mm-hotfixes tree, today's linux-next build (arm
> > allmodconfig) failed like this:
> > 
> > mm/vmscan.c:4090:9: error: implicit declaration of function ‘pmd_young’; did you mean ‘pte_young’? [-Werror=implicit-function-declaration]
> > 
> > Caused by commit
> > 
> >   3f85e711d5af ("mm: introduce arch_has_hw_nonleaf_pmd_young()")
> > 
> > This error was found by the kernel.ci bot and so is still int today's
> > tree.  
> 
> Thanks.  Did that tree include "mm: add dummy pmd_young() for
> architectures not having it"?

It did not when I merged the mm-hotfixes branch, but then I refetched
your trees during the day and so that patch appeared when I merged the
mm tree (which is now based on a later version of the mm-hotfixes
branch). So next-20221125 as a whole will not have the build failure.

After I merge all the "fixes" branches, I upload a "pending-updates"
branch that feeds into the various bots independently of the full next
tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]