From: Dan Carpenter <dan.carpenter@linaro.org>
To: oe-kbuild@lists.linux.dev, Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: [akpm-mm:mm-new 203/214] mm/mremap.c:1829 remap_move() error: uninitialized symbol 'last_end'.
Date: Mon, 14 Jul 2025 22:35:12 +0300 [thread overview]
Message-ID: <9c8287d3-59e9-48c7-8504-bf51eb3d5a50@suswa.mountain> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-new
head: 9911a6d0676c211ea4df7eb8fe82ee6a0bb64fb4
commit: f1d4bfd28bb6e2e82f5fc58c7a0e17b7e15bba29 [203/214] mm/mremap: permit mremap() move of multiple VMAs
config: x86_64-randconfig-161-20250711 (https://download.01.org/0day-ci/archive/20250712/202507120401.DCzwzjow-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
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>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202507120401.DCzwzjow-lkp@intel.com/
smatch warnings:
mm/mremap.c:1829 remap_move() error: uninitialized symbol 'last_end'.
vim +/last_end +1829 mm/mremap.c
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1785 static unsigned long remap_move(struct vma_remap_struct *vrm)
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1786 {
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1787 struct vm_area_struct *vma;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1788 unsigned long start = vrm->addr;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1789 unsigned long end = vrm->addr + vrm->old_len;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1790 unsigned long new_addr = vrm->new_addr;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1791 unsigned long prev_addr = start;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1792 VMA_ITERATOR(vmi, current->mm, start);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1793 unsigned long res = -EFAULT;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1794 unsigned long last_end;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1795
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1796 /*
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1797 * When moving VMAs we allow for batched moves across multiple VMAs,
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1798 * with all VMAs in the input range [addr, addr + old_len) being moved
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1799 * (and split as necessary).
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1800 */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1801 for_each_vma_range(vmi, vma, end) {
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1802 /* Account for start, end not aligned with VMA start, end. */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1803 unsigned long addr = max(vma->vm_start, start);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1804 unsigned long len = min(end, vma->vm_end) - addr;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1805 unsigned long offset, res_vma;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1806
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1807 /* Merged with self, move on. */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1808 if (vrm->multi_vma && prev_addr == addr)
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1809 continue;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1810
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1811 /*
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1812 * To sensibly move multiple VMAs, accounting for the fact that
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1813 * get_unmapped_area() may align even MAP_FIXED moves, we simply
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1814 * attempt to move such that the gaps between source VMAs remain
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1815 * consistent in destination VMAs, e.g.:
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1816 *
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1817 * X Y X Y
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1818 * <---> <-> <---> <->
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1819 * |-------| |-----| |-----| |-------| |-----| |-----|
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1820 * | A | | B | | C | ---> | A' | | B' | | C' |
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1821 * |-------| |-----| |-----| |-------| |-----| |-----|
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1822 * new_addr
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1823 *
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1824 * Now, new_addr may be altered even with MREMAP_FIXED set, due
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1825 * to e.g. alignment changes from get_unmapped_area().
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1826 *
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1827 * So we map B' at A'->vm_end + X, and C' at B'->vm_end + Y.
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1828 */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 @1829 offset = vrm->multi_vma ? vma->vm_start - last_end : 0;
^^^^^^^^
The "last_end" variable is set on the next line. I don't know the
starting value of vrm->multi_vma so it's possible that this is a false
positive but it seems like a legit issue at first glance.
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1830 last_end = vma->vm_end;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1831
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1832 vrm->vma = vma;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1833 vrm->addr = addr;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1834 vrm->new_addr = new_addr + offset;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1835 vrm->old_len = vrm->new_len = len;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1836
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1837 res_vma = check_prep_vma(vrm);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1838 if (!res_vma)
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1839 res_vma = mremap_to(vrm);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1840 if (IS_ERR_VALUE(res_vma))
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1841 return res_vma;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1842
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1843 /* mmap lock is only dropped on shrink. */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1844 VM_WARN_ON_ONCE(!vrm->mmap_locked);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1845 /* This is a move, no expand should occur. */
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1846 VM_WARN_ON_ONCE(vrm->populate_expand);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1847
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1848 if (!vrm->multi_vma)
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1849 res = res_vma;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1850
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1851 if (vrm->vmi_needs_reset) {
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1852 vma_iter_reset(&vmi);
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1853 vrm->vmi_needs_reset = false;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1854 }
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1855 vrm->multi_vma = true;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1856 prev_addr = addr;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1857 new_addr = res_vma + vrm->new_len;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1858 }
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1859
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1860 return res;
f1d4bfd28bb6e2 Lorenzo Stoakes 2025-07-10 1861 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2025-07-14 19:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 19:35 Dan Carpenter [this message]
2025-07-15 3:52 ` Lorenzo Stoakes
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=9c8287d3-59e9-48c7-8504-bf51eb3d5a50@suswa.mountain \
--to=dan.carpenter@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox