All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.