From: kernel test robot <lkp@intel.com>
To: Kalesh Singh <kaleshsingh@google.com>,
akpm@linux-foundation.org, minchan@kernel.org,
lorenzo.stoakes@oracle.com, david@redhat.com,
Liam.Howlett@oracle.com, rppt@kernel.org, pfalcato@suse.de
Cc: oe-kbuild-all@lists.linux.dev, kernel-team@android.com,
android-mm@google.com, Kalesh Singh <kaleshsingh@google.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Kees Cook <kees@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
Jann Horn <jannh@google.com>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v2 3/7] mm: introduce vma_count_remaining()
Date: Wed, 17 Sep 2025 02:33:46 +0800 [thread overview]
Message-ID: <202509170238.NUURxWPI-lkp@intel.com> (raw)
In-Reply-To: <20250915163838.631445-4-kaleshsingh@google.com>
Hi Kalesh,
kernel test robot noticed the following build errors:
[auto build test ERROR on f83ec76bf285bea5727f478a68b894f5543ca76e]
url: https://github.com/intel-lab-lkp/linux/commits/Kalesh-Singh/mm-fix-off-by-one-error-in-VMA-count-limit-checks/20250916-005018
base: f83ec76bf285bea5727f478a68b894f5543ca76e
patch link: https://lore.kernel.org/r/20250915163838.631445-4-kaleshsingh%40google.com
patch subject: [PATCH v2 3/7] mm: introduce vma_count_remaining()
config: s390-randconfig-r122-20250916 (https://download.01.org/0day-ci/archive/20250917/202509170238.NUURxWPI-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 13.4.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250917/202509170238.NUURxWPI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509170238.NUURxWPI-lkp@intel.com/
All errors (new ones prefixed by >>):
s390-linux-ld: mm/mmap.o: in function `do_mmap':
>> mm/mmap.c:377:(.text+0x6566): undefined reference to `vma_count_remaining'
s390-linux-ld: mm/mremap.o: in function `prep_move_vma':
>> mm/mremap.c:1043:(.text+0x199a): undefined reference to `vma_count_remaining'
s390-linux-ld: mm/mremap.o: in function `check_mremap_params':
mm/mremap.c:1820:(.text+0x4044): undefined reference to `vma_count_remaining'
s390-linux-ld: mm/vma.o: in function `vms_gather_munmap_vmas':
>> mm/vma.c:1348:(.text+0x8ebc): undefined reference to `vma_count_remaining'
s390-linux-ld: mm/vma.o: in function `split_vma':
mm/vma.c:595:(.text+0xa2a2): undefined reference to `vma_count_remaining'
s390-linux-ld: mm/vma.o:mm/vma.c:2775: more undefined references to `vma_count_remaining' follow
vim +377 mm/mmap.c
276
277 /**
278 * do_mmap() - Perform a userland memory mapping into the current process
279 * address space of length @len with protection bits @prot, mmap flags @flags
280 * (from which VMA flags will be inferred), and any additional VMA flags to
281 * apply @vm_flags. If this is a file-backed mapping then the file is specified
282 * in @file and page offset into the file via @pgoff.
283 *
284 * This function does not perform security checks on the file and assumes, if
285 * @uf is non-NULL, the caller has provided a list head to track unmap events
286 * for userfaultfd @uf.
287 *
288 * It also simply indicates whether memory population is required by setting
289 * @populate, which must be non-NULL, expecting the caller to actually perform
290 * this task itself if appropriate.
291 *
292 * This function will invoke architecture-specific (and if provided and
293 * relevant, file system-specific) logic to determine the most appropriate
294 * unmapped area in which to place the mapping if not MAP_FIXED.
295 *
296 * Callers which require userland mmap() behaviour should invoke vm_mmap(),
297 * which is also exported for module use.
298 *
299 * Those which require this behaviour less security checks, userfaultfd and
300 * populate behaviour, and who handle the mmap write lock themselves, should
301 * call this function.
302 *
303 * Note that the returned address may reside within a merged VMA if an
304 * appropriate merge were to take place, so it doesn't necessarily specify the
305 * start of a VMA, rather only the start of a valid mapped range of length
306 * @len bytes, rounded down to the nearest page size.
307 *
308 * The caller must write-lock current->mm->mmap_lock.
309 *
310 * @file: An optional struct file pointer describing the file which is to be
311 * mapped, if a file-backed mapping.
312 * @addr: If non-zero, hints at (or if @flags has MAP_FIXED set, specifies) the
313 * address at which to perform this mapping. See mmap (2) for details. Must be
314 * page-aligned.
315 * @len: The length of the mapping. Will be page-aligned and must be at least 1
316 * page in size.
317 * @prot: Protection bits describing access required to the mapping. See mmap
318 * (2) for details.
319 * @flags: Flags specifying how the mapping should be performed, see mmap (2)
320 * for details.
321 * @vm_flags: VMA flags which should be set by default, or 0 otherwise.
322 * @pgoff: Page offset into the @file if file-backed, should be 0 otherwise.
323 * @populate: A pointer to a value which will be set to 0 if no population of
324 * the range is required, or the number of bytes to populate if it is. Must be
325 * non-NULL. See mmap (2) for details as to under what circumstances population
326 * of the range occurs.
327 * @uf: An optional pointer to a list head to track userfaultfd unmap events
328 * should unmapping events arise. If provided, it is up to the caller to manage
329 * this.
330 *
331 * Returns: Either an error, or the address at which the requested mapping has
332 * been performed.
333 */
334 unsigned long do_mmap(struct file *file, unsigned long addr,
335 unsigned long len, unsigned long prot,
336 unsigned long flags, vm_flags_t vm_flags,
337 unsigned long pgoff, unsigned long *populate,
338 struct list_head *uf)
339 {
340 struct mm_struct *mm = current->mm;
341 int pkey = 0;
342
343 *populate = 0;
344
345 mmap_assert_write_locked(mm);
346
347 if (!len)
348 return -EINVAL;
349
350 /*
351 * Does the application expect PROT_READ to imply PROT_EXEC?
352 *
353 * (the exception is when the underlying filesystem is noexec
354 * mounted, in which case we don't add PROT_EXEC.)
355 */
356 if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
357 if (!(file && path_noexec(&file->f_path)))
358 prot |= PROT_EXEC;
359
360 /* force arch specific MAP_FIXED handling in get_unmapped_area */
361 if (flags & MAP_FIXED_NOREPLACE)
362 flags |= MAP_FIXED;
363
364 if (!(flags & MAP_FIXED))
365 addr = round_hint_to_min(addr);
366
367 /* Careful about overflows.. */
368 len = PAGE_ALIGN(len);
369 if (!len)
370 return -ENOMEM;
371
372 /* offset overflow? */
373 if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)
374 return -EOVERFLOW;
375
376 /* Too many mappings? */
> 377 if (!vma_count_remaining(mm))
378 return -ENOMEM;
379
380 /*
381 * addr is returned from get_unmapped_area,
382 * There are two cases:
383 * 1> MAP_FIXED == false
384 * unallocated memory, no need to check sealing.
385 * 1> MAP_FIXED == true
386 * sealing is checked inside mmap_region when
387 * do_vmi_munmap is called.
388 */
389
390 if (prot == PROT_EXEC) {
391 pkey = execute_only_pkey(mm);
392 if (pkey < 0)
393 pkey = 0;
394 }
395
396 /* Do simple checking here so the lower-level routines won't have
397 * to. we assume access permissions have been handled by the open
398 * of the memory object, so we don't do any here.
399 */
400 vm_flags |= calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(file, flags) |
401 mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
402
403 /* Obtain the address to map to. we verify (or select) it and ensure
404 * that it represents a valid section of the address space.
405 */
406 addr = __get_unmapped_area(file, addr, len, pgoff, flags, vm_flags);
407 if (IS_ERR_VALUE(addr))
408 return addr;
409
410 if (flags & MAP_FIXED_NOREPLACE) {
411 if (find_vma_intersection(mm, addr, addr + len))
412 return -EEXIST;
413 }
414
415 if (flags & MAP_LOCKED)
416 if (!can_do_mlock())
417 return -EPERM;
418
419 if (!mlock_future_ok(mm, vm_flags, len))
420 return -EAGAIN;
421
422 if (file) {
423 struct inode *inode = file_inode(file);
424 unsigned long flags_mask;
425 int err;
426
427 if (!file_mmap_ok(file, inode, pgoff, len))
428 return -EOVERFLOW;
429
430 flags_mask = LEGACY_MAP_MASK;
431 if (file->f_op->fop_flags & FOP_MMAP_SYNC)
432 flags_mask |= MAP_SYNC;
433
434 switch (flags & MAP_TYPE) {
435 case MAP_SHARED:
436 /*
437 * Force use of MAP_SHARED_VALIDATE with non-legacy
438 * flags. E.g. MAP_SYNC is dangerous to use with
439 * MAP_SHARED as you don't know which consistency model
440 * you will get. We silently ignore unsupported flags
441 * with MAP_SHARED to preserve backward compatibility.
442 */
443 flags &= LEGACY_MAP_MASK;
444 fallthrough;
445 case MAP_SHARED_VALIDATE:
446 if (flags & ~flags_mask)
447 return -EOPNOTSUPP;
448 if (prot & PROT_WRITE) {
449 if (!(file->f_mode & FMODE_WRITE))
450 return -EACCES;
451 if (IS_SWAPFILE(file->f_mapping->host))
452 return -ETXTBSY;
453 }
454
455 /*
456 * Make sure we don't allow writing to an append-only
457 * file..
458 */
459 if (IS_APPEND(inode) && (file->f_mode & FMODE_WRITE))
460 return -EACCES;
461
462 vm_flags |= VM_SHARED | VM_MAYSHARE;
463 if (!(file->f_mode & FMODE_WRITE))
464 vm_flags &= ~(VM_MAYWRITE | VM_SHARED);
465 fallthrough;
466 case MAP_PRIVATE:
467 if (!(file->f_mode & FMODE_READ))
468 return -EACCES;
469 if (path_noexec(&file->f_path)) {
470 if (vm_flags & VM_EXEC)
471 return -EPERM;
472 vm_flags &= ~VM_MAYEXEC;
473 }
474
475 if (!can_mmap_file(file))
476 return -ENODEV;
477 if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
478 return -EINVAL;
479 break;
480
481 default:
482 return -EINVAL;
483 }
484
485 /*
486 * Check to see if we are violating any seals and update VMA
487 * flags if necessary to avoid future seal violations.
488 */
489 err = memfd_check_seals_mmap(file, &vm_flags);
490 if (err)
491 return (unsigned long)err;
492 } else {
493 switch (flags & MAP_TYPE) {
494 case MAP_SHARED:
495 if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))
496 return -EINVAL;
497 /*
498 * Ignore pgoff.
499 */
500 pgoff = 0;
501 vm_flags |= VM_SHARED | VM_MAYSHARE;
502 break;
503 case MAP_DROPPABLE:
504 if (VM_DROPPABLE == VM_NONE)
505 return -ENOTSUPP;
506 /*
507 * A locked or stack area makes no sense to be droppable.
508 *
509 * Also, since droppable pages can just go away at any time
510 * it makes no sense to copy them on fork or dump them.
511 *
512 * And don't attempt to combine with hugetlb for now.
513 */
514 if (flags & (MAP_LOCKED | MAP_HUGETLB))
515 return -EINVAL;
516 if (vm_flags & (VM_GROWSDOWN | VM_GROWSUP))
517 return -EINVAL;
518
519 vm_flags |= VM_DROPPABLE;
520
521 /*
522 * If the pages can be dropped, then it doesn't make
523 * sense to reserve them.
524 */
525 vm_flags |= VM_NORESERVE;
526
527 /*
528 * Likewise, they're volatile enough that they
529 * shouldn't survive forks or coredumps.
530 */
531 vm_flags |= VM_WIPEONFORK | VM_DONTDUMP;
532 fallthrough;
533 case MAP_PRIVATE:
534 /*
535 * Set pgoff according to addr for anon_vma.
536 */
537 pgoff = addr >> PAGE_SHIFT;
538 break;
539 default:
540 return -EINVAL;
541 }
542 }
543
544 /*
545 * Set 'VM_NORESERVE' if we should not account for the
546 * memory use of this mapping.
547 */
548 if (flags & MAP_NORESERVE) {
549 /* We honor MAP_NORESERVE if allowed to overcommit */
550 if (sysctl_overcommit_memory != OVERCOMMIT_NEVER)
551 vm_flags |= VM_NORESERVE;
552
553 /* hugetlb applies strict overcommit unless MAP_NORESERVE */
554 if (file && is_file_hugepages(file))
555 vm_flags |= VM_NORESERVE;
556 }
557
558 addr = mmap_region(file, addr, len, vm_flags, pgoff, uf);
559 if (!IS_ERR_VALUE(addr) &&
560 ((vm_flags & VM_LOCKED) ||
561 (flags & (MAP_POPULATE | MAP_NONBLOCK)) == MAP_POPULATE))
562 *populate = len;
563 return addr;
564 }
565
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-09-16 18:34 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 16:36 [PATCH v2 0/7] vma count: fixes, test and improvements Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 1/7] mm: fix off-by-one error in VMA count limit checks Kalesh Singh
2025-09-15 22:36 ` Andrew Morton
2025-09-16 14:20 ` Jonathan Corbet
2025-09-17 1:16 ` Andrew Morton
2025-09-16 9:45 ` Pedro Falcato
2025-09-17 7:44 ` SeongJae Park
2025-09-17 10:52 ` David Hildenbrand
2025-09-18 11:31 ` Pedro Falcato
2025-09-18 13:53 ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 2/7] mm/selftests: add max_vma_count tests Kalesh Singh
2025-09-17 10:58 ` David Hildenbrand
2025-09-17 16:49 ` Kalesh Singh
2025-09-18 14:42 ` Lorenzo Stoakes
2025-09-18 16:21 ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 3/7] mm: introduce vma_count_remaining() Kalesh Singh
2025-09-16 18:33 ` kernel test robot [this message]
2025-09-18 14:10 ` Lorenzo Stoakes
2025-09-17 13:38 ` David Hildenbrand
2025-09-17 17:10 ` Kalesh Singh
2025-09-18 13:20 ` Lorenzo Stoakes
2025-09-18 13:26 ` Lorenzo Stoakes
2025-09-18 14:31 ` Lorenzo Stoakes
2025-09-18 15:52 ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 4/7] mm: rename mm_struct::map_count to vma_count Kalesh Singh
2025-09-17 13:41 ` David Hildenbrand
2025-09-18 11:46 ` Pedro Falcato
2025-09-18 14:48 ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 5/7] mm: harden vma_count against direct modification Kalesh Singh
2025-09-16 9:10 ` kernel test robot
2025-09-18 14:52 ` Lorenzo Stoakes
2025-09-18 15:43 ` Kalesh Singh
2025-09-15 16:36 ` [PATCH v2 6/7] mm: add assertion for VMA count limit Kalesh Singh
2025-09-17 13:44 ` David Hildenbrand
2025-09-17 17:22 ` Kalesh Singh
2025-09-17 18:34 ` David Hildenbrand
2025-09-17 20:31 ` Kalesh Singh
2025-09-18 11:48 ` Pedro Falcato
2025-09-18 13:30 ` Lorenzo Stoakes
2025-09-15 16:36 ` [PATCH v2 7/7] mm/tracing: introduce max_vma_count_exceeded trace event Kalesh Singh
2025-09-15 23:41 ` Steven Rostedt
2025-09-16 1:19 ` Kalesh Singh
2025-09-16 15:52 ` Steven Rostedt
2025-09-16 17:36 ` Kalesh Singh
2025-09-16 17:48 ` Steven Rostedt
2025-09-16 17:57 ` Kalesh Singh
2025-09-16 18:02 ` Steven Rostedt
2025-09-16 18:23 ` Kalesh Singh
2025-09-16 18:51 ` Steven Rostedt
2025-09-16 20:08 ` Kalesh Singh
2025-09-18 11:38 ` Pedro Falcato
2025-09-18 14:48 ` Steven Rostedt
2025-09-18 13:42 ` Lorenzo Stoakes
2025-09-18 13:51 ` Lorenzo Stoakes
2025-09-18 15:55 ` Kalesh Singh
2025-09-15 22:34 ` [PATCH v2 0/7] vma count: fixes, test and improvements Andrew Morton
2025-09-15 23:10 ` Kalesh Singh
2025-09-16 0:05 ` Andrew Morton
2025-09-16 1:23 ` Kalesh Singh
2025-09-16 10:12 ` Lorenzo Stoakes
2025-09-16 17:47 ` Kalesh Singh
2025-09-17 2:16 ` Andrew Morton
2025-09-17 5:36 ` Lorenzo Stoakes
2025-09-17 23:32 ` Andrew Morton
2025-09-18 10:29 ` Lorenzo Stoakes
2025-09-18 12:07 ` David Hildenbrand
2025-09-18 12:49 ` Lorenzo Stoakes
2025-09-18 20:59 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202509170238.NUURxWPI-lkp@intel.com \
--to=lkp@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=android-mm@google.com \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=david@redhat.com \
--cc=dietmar.eggemann@arm.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=kaleshsingh@google.com \
--cc=kees@kernel.org \
--cc=kernel-team@android.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.