* [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487
@ 2026-07-25 7:11 kernel test robot
2026-07-26 2:31 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: kernel test robot @ 2026-07-25 7:11 UTC (permalink / raw)
To: David Hildenbrand; +Cc: Andrew Morton, Linux Memory Management List, mm-commits
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
branch HEAD: 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487 mm/swap, PM: hibernate: atomically replace hibernation pin
Unverified Warning (likely false positive, kindly check if interested):
https://lore.kernel.org/oe-kbuild/202607021433.DYT5fDqE-lkp@intel.com
https://lore.kernel.org/oe-kbuild/202607120402.clBrrZQA-lkp@intel.com
mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654)
mm/vmpressure.c:123 vmpressure() warn: check likely/unlikely parentheses
Warning ids grouped by kconfigs:
recent_errors
|-- microblaze-randconfig-r072-20260725
| `-- mm-hmm.c-hmm_do_fault()-error:we-previously-assumed-hmm_vma_walk-locked-could-be-null-(see-line-)
`-- um-randconfig-r073-20260725
|-- mm-hmm.c-hmm_do_fault()-error:we-previously-assumed-hmm_vma_walk-locked-could-be-null-(see-line-)
`-- mm-vmpressure.c-vmpressure()-warn:check-likely-unlikely-parentheses
elapsed time: 998m
configs tested: 92
configs skipped: 8
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig gcc-16.1.0
arc allyesconfig gcc-16.1.0
arc randconfig-001-20260725 gcc-11.5.0
arc randconfig-002-20260725 gcc-8.5.0
arm randconfig-001-20260725 gcc-8.5.0
arm randconfig-002-20260725 clang-21
arm randconfig-003-20260725 gcc-10.5.0
arm randconfig-004-20260725 gcc-15.2.0
arm64 randconfig-001-20260725 clang-24
arm64 randconfig-002-20260725 gcc-13.4.0
arm64 randconfig-003-20260725 clang-24
arm64 randconfig-004-20260725 clang-24
csky allmodconfig gcc-16.1.0
csky randconfig-001-20260725 gcc-9.5.0
csky randconfig-002-20260725 gcc-16.1.0
hexagon randconfig-001 clang-17
hexagon randconfig-001-20260725 clang-17
hexagon randconfig-002-20260725 clang-24
i386 allmodconfig gcc-14
i386 buildonly-randconfig-001-20260725 clang-22
i386 buildonly-randconfig-002-20260725 gcc-14
i386 buildonly-randconfig-003-20260725 clang-22
i386 buildonly-randconfig-004-20260725 clang-22
i386 buildonly-randconfig-005-20260725 gcc-14
i386 buildonly-randconfig-006-20260725 gcc-14
i386 randconfig-001-20260725 clang-22
i386 randconfig-002-20260725 gcc-14
i386 randconfig-003-20260725 gcc-14
i386 randconfig-004-20260725 gcc-12
i386 randconfig-005-20260725 clang-22
i386 randconfig-006-20260725 gcc-14
i386 randconfig-007-20260725 gcc-14
i386 randconfig-011-20260725 gcc-14
i386 randconfig-012-20260725 gcc-14
i386 randconfig-013-20260725 gcc-14
i386 randconfig-014-20260725 clang-22
i386 randconfig-015-20260725 clang-22
i386 randconfig-016-20260725 clang-22
i386 randconfig-017-20260725 clang-22
loongarch defconfig clang-24
loongarch randconfig-001-20260725 gcc-16.1.0
loongarch randconfig-002-20260725 gcc-13.4.0
m68k m5249evb_defconfig gcc-16.1.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 randconfig-001-20260725 gcc-11.5.0
nios2 randconfig-002-20260725 gcc-9.5.0
parisc allmodconfig gcc-16.1.0
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260725 gcc-10.5.0
parisc randconfig-002-20260725 gcc-12.5.0
powerpc randconfig-001-20260725 gcc-9.5.0
powerpc randconfig-002-20260725 gcc-15.2.0
powerpc64 randconfig-001-20260725 clang-17
powerpc64 randconfig-002-20260725 clang-24
riscv randconfig-001-20260725 gcc-8.5.0
riscv randconfig-002-20260725 gcc-8.5.0
s390 randconfig-001-20260725 gcc-10.5.0
s390 randconfig-002-20260725 gcc-16.1.0
sh defconfig gcc-16.1.0
sh randconfig-001-20260725 gcc-16.1.0
sh randconfig-002-20260725 gcc-11.5.0
sparc randconfig-001-20260725 gcc-16.1.0
sparc randconfig-002-20260725 gcc-8.5.0
sparc64 randconfig-001-20260725 gcc-8.5.0
sparc64 randconfig-002-20260725 gcc-10.5.0
um randconfig-001-20260725 gcc-14
um randconfig-002-20260725 clang-24
x86_64 randconfig-001-20260725 gcc-14
x86_64 randconfig-002-20260725 clang-22
x86_64 randconfig-003-20260725 clang-22
x86_64 randconfig-004-20260725 clang-22
x86_64 randconfig-005-20260725 clang-22
x86_64 randconfig-006-20260725 clang-22
x86_64 randconfig-011-20260725 gcc-14
x86_64 randconfig-012-20260725 gcc-14
x86_64 randconfig-013-20260725 gcc-14
x86_64 randconfig-014-20260725 gcc-14
x86_64 randconfig-015-20260725 gcc-14
x86_64 randconfig-016-20260725 gcc-14
x86_64 randconfig-071-20260725 gcc-14
x86_64 randconfig-072-20260725 gcc-14
x86_64 randconfig-073-20260725 gcc-14
x86_64 randconfig-074-20260725 gcc-14
x86_64 randconfig-075-20260725 gcc-14
x86_64 randconfig-076-20260725 clang-22
xtensa randconfig-001-20260725 gcc-16.1.0
xtensa randconfig-002-20260725 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487
2026-07-25 7:11 [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487 kernel test robot
@ 2026-07-26 2:31 ` Andrew Morton
2026-07-26 18:41 ` Stanislav Kinsburskii
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2026-07-26 2:31 UTC (permalink / raw)
To: kernel test robot
Cc: David Hildenbrand, Linux Memory Management List, mm-commits,
Stanislav Kinsburskii, Jason Gunthorpe, Leon Romanovsky
Thanks. A few head-scratchers for hmm people, please:
On Sat, 25 Jul 2026 15:11:38 +0800 kernel test robot <lkp@intel.com> wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
> branch HEAD: 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487 mm/swap, PM: hibernate: atomically replace hibernation pin
>
> Unverified Warning (likely false positive, kindly check if interested):
>
> https://lore.kernel.org/oe-kbuild/202607021433.DYT5fDqE-lkp@intel.com
> https://lore.kernel.org/oe-kbuild/202607120402.clBrrZQA-lkp@intel.com
>
> mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654)
> mm/vmpressure.c:123 vmpressure() warn: check likely/unlikely parentheses
>
> Warning ids grouped by kconfigs:
>
> recent_errors
> |-- microblaze-randconfig-r072-20260725
> | `-- mm-hmm.c-hmm_do_fault()-error:we-previously-assumed-hmm_vma_walk-locked-could-be-null-(see-line-)
With this microblaze config on current mainline I hit
mm/hmm.c:804:25: error: implicit declaration of function 'mmu_interval_read_begin'; did you mean 'mmu_interval_check_retry'? [-Wimplicit-function-declaration]
804 | mmu_interval_read_begin(range->notifier);
And after adding the hmm changes from mm-unstable I also hit
mm/hmm.c:805:25: error: implicit declaration of function 'mmu_interval_read_begin'; did you mean 'mmu_interval_check_retry'? [-Wimplicit-function-declaration]
805 | mmu_interval_read_begin(range->notifier);
| ^~~~~~~~~~~~~~~~~~~~~~~
| mmu_interval_check_retry
Both of which can be fixed with
--- a/include/linux/mmu_notifier.h~a
+++ a/include/linux/mmu_notifier.h
@@ -576,6 +576,19 @@ static inline void _mmu_notifier_range_i
_mmu_notifier_range_init(range, start, end)
static inline bool
+mmu_interval_check_retry(struct mmu_interval_notifier *interval_sub,
+ unsigned long seq)
+{
+ return true;
+}
+
+static inline unsigned long
+mmu_interval_read_begin(struct mmu_interval_notifier *interval_sub)
+{
+ return 0;
+}
+
+static inline bool
mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
{
return true;
But I do wonder whether we should be compiling hmm at all if
CONFIG_MMU_NOTIFIER=n?
And your hmm_do_fault() warning seems legit:
if (hmm_vma_walk->locked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
...
*hmm_vma_walk->locked = false;
and the blame seems to lie with Stanislav's "mm/hmm: add
hmm_range_fault_unlocked_timeout() for mmap lock-drop support".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487
2026-07-26 2:31 ` Andrew Morton
@ 2026-07-26 18:41 ` Stanislav Kinsburskii
2026-07-28 0:38 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Stanislav Kinsburskii @ 2026-07-26 18:41 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel test robot, David Hildenbrand,
Linux Memory Management List, mm-commits, Jason Gunthorpe,
Leon Romanovsky
On Sat, Jul 25, 2026 at 07:31:55PM -0700, Andrew Morton wrote:
>
> Thanks. A few head-scratchers for hmm people, please:
>
> On Sat, 25 Jul 2026 15:11:38 +0800 kernel test robot <lkp@intel.com> wrote:
>
> > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
> > branch HEAD: 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487 mm/swap, PM: hibernate: atomically replace hibernation pin
> >
> > Unverified Warning (likely false positive, kindly check if interested):
> >
> > https://lore.kernel.org/oe-kbuild/202607021433.DYT5fDqE-lkp@intel.com
> > https://lore.kernel.org/oe-kbuild/202607120402.clBrrZQA-lkp@intel.com
> >
> > mm/hmm.c:673 hmm_do_fault() error: we previously assumed 'hmm_vma_walk->locked' could be null (see line 654)
> > mm/vmpressure.c:123 vmpressure() warn: check likely/unlikely parentheses
> >
> > Warning ids grouped by kconfigs:
> >
> > recent_errors
> > |-- microblaze-randconfig-r072-20260725
> > | `-- mm-hmm.c-hmm_do_fault()-error:we-previously-assumed-hmm_vma_walk-locked-could-be-null-(see-line-)
>
> With this microblaze config on current mainline I hit
>
> mm/hmm.c:804:25: error: implicit declaration of function 'mmu_interval_read_begin'; did you mean 'mmu_interval_check_retry'? [-Wimplicit-function-declaration]
> 804 | mmu_interval_read_begin(range->notifier);
>
> And after adding the hmm changes from mm-unstable I also hit
>
> mm/hmm.c:805:25: error: implicit declaration of function 'mmu_interval_read_begin'; did you mean 'mmu_interval_check_retry'? [-Wimplicit-function-declaration]
> 805 | mmu_interval_read_begin(range->notifier);
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | mmu_interval_check_retry
>
> Both of which can be fixed with
>
> --- a/include/linux/mmu_notifier.h~a
> +++ a/include/linux/mmu_notifier.h
> @@ -576,6 +576,19 @@ static inline void _mmu_notifier_range_i
> _mmu_notifier_range_init(range, start, end)
>
> static inline bool
> +mmu_interval_check_retry(struct mmu_interval_notifier *interval_sub,
> + unsigned long seq)
> +{
> + return true;
> +}
> +
> +static inline unsigned long
> +mmu_interval_read_begin(struct mmu_interval_notifier *interval_sub)
> +{
> + return 0;
> +}
> +
> +static inline bool
> mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
> {
> return true;
>
> But I do wonder whether we should be compiling hmm at all if
> CONFIG_MMU_NOTIFIER=n?
>
Documentation/mm/hmm.rst explicitly states:
"Address space mirroring's main objective is to allow duplication of a range of
CPU page table into a device page table; HMM helps keep both synchronized. A
device driver that wants to mirror a process address space must start with the
registration of a mmu_interval_notifier"
I think making CONFIG_HMM_MIRROR dependent on the CONFIG_MMU_NOTIFIER is the right thing to do.
>
> And your hmm_do_fault() warning seems legit:
>
> if (hmm_vma_walk->locked)
> fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
>
> ...
> *hmm_vma_walk->locked = false;
>
> and the blame seems to lie with Stanislav's "mm/hmm: add
> hmm_range_fault_unlocked_timeout() for mmap lock-drop support".
>
Well, this is the same behavior as in fixup_user_fault().
The fault handler is not supposed to return either VM_FAULT_COMPLETED or
VM_FAULT_RETRY unless FAULT_FLAG_ALLOW_RETRY is set, and that flag is
set only if hmm_vma_walk->locked is not NULL.
In other words, only buggy fault handlers can trigger this NULL pointer
dereference, and I thought we had agreed that we do not try to support
those.
Let me know if you think otherwise and I'll send an update.
Thanks, Stanislav
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487
2026-07-26 18:41 ` Stanislav Kinsburskii
@ 2026-07-28 0:38 ` Andrew Morton
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Morton @ 2026-07-28 0:38 UTC (permalink / raw)
To: Stanislav Kinsburskii
Cc: kernel test robot, David Hildenbrand,
Linux Memory Management List, mm-commits, Jason Gunthorpe,
Leon Romanovsky
On Sun, 26 Jul 2026 11:41:26 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > But I do wonder whether we should be compiling hmm at all if
> > CONFIG_MMU_NOTIFIER=n?
> >
>
> Documentation/mm/hmm.rst explicitly states:
>
> "Address space mirroring's main objective is to allow duplication of a range of
> CPU page table into a device page table; HMM helps keep both synchronized. A
> device driver that wants to mirror a process address space must start with the
> registration of a mmu_interval_notifier"
>
> I think making CONFIG_HMM_MIRROR dependent on the CONFIG_MMU_NOTIFIER is the right thing to do.
OK, thanks. How about we use select. select kinda sucks but we're
doing `select MMU_NOTIFIER' all over the place already.
From: Andrew Morton <akpm@linux-foundation.org>
Subject: mm/hmm: make CONFIG_HMM_MIRROR select CONFIG_MMU_NOTIFIER
Date: Mon Jul 27 05:31:14 PM PDT 2026
hmm doesn't currently build well with MMU_NOTIFIER=n:
With microblaze
https://download.01.org/0day-ci/archive/20260702/202607021433.DYT5fDqE-lkp@intel.com/config
(CONFIG_MMU_NOTIFIER=n):
mm/hmm.c: In function 'hmm_range_fault_unlocked_timeout':
mm/hmm.c:804:25: error: implicit declaration of function 'mmu_interval_read_begin'; did you mean 'mmu_interval_check_retry'? [-Wimplicit-function-declaration]
804 | mmu_interval_read_begin(range->notifier);
| ^~~~~~~~~~~~~~~~~~~~~~~
| mmu_interval_check_retry
Quoting Stanislav:
: Documentation/mm/hmm.rst explicitly states:
:
: "Address space mirroring's main objective is to allow duplication of a
: range of CPU page table into a device page table; HMM helps keep both
: synchronized. A device driver that wants to mirror a process address
: space must start with the registration of a mmu_interval_notifier"
:
: I think making CONFIG_HMM_MIRROR dependent on the CONFIG_MMU_NOTIFIER
: is the right thing to do.
So select MMU_NOTIFIER if hmm.c is to be compiled.
Cc: David Hildenbrand <david@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Stanislav Kinsburskii <skinsburskii@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/mm/Kconfig~mm-hmm-make-config_hmm_mirror-select-config_mmu_notifier
+++ a/mm/Kconfig
@@ -1250,6 +1250,7 @@ config ZONE_DEVICE
config HMM_MIRROR
bool
depends on MMU
+ select MMU_NOTIFIER
config GET_FREE_REGION
bool
_
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-07-28 0:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-25 7:11 [akpm-mm:mm-new] BUILD SUCCESS WITH UNVERIFIED WARNING 34cacd0ac7c10dc9e34e1b9f28a2b78d335cb487 kernel test robot
2026-07-26 2:31 ` Andrew Morton
2026-07-26 18:41 ` Stanislav Kinsburskii
2026-07-28 0:38 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox