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