From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: oe-kbuild@lists.linux.dev, lkp@intel.com,
oe-kbuild-all@lists.linux.dev,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [akpm-mm:mm-new 203/214] mm/mremap.c:1829 remap_move() error: uninitialized symbol 'last_end'.
Date: Tue, 15 Jul 2025 04:52:56 +0100 [thread overview]
Message-ID: <404e240c-cba4-4d55-bcb1-dd49eab09bbb@lucifer.local> (raw)
In-Reply-To: <9c8287d3-59e9-48c7-8504-bf51eb3d5a50@suswa.mountain>
On Mon, Jul 14, 2025 at 10:35:12PM +0300, Dan Carpenter wrote:
> 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.
It's a false positive.
vrm->multi_vma starts off false, and is only set to true at a point last_end is
assigned to.
The new version of this series which presumably hasn't wound its way to -next
yet uses a local variable instead of vrm->multi_vma which makes this clearer.
prev parent reply other threads:[~2025-07-15 3:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-14 19:35 Dan Carpenter
2025-07-15 3:52 ` Lorenzo Stoakes [this message]
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=404e240c-cba4-4d55-bcb1-dd49eab09bbb@lucifer.local \
--to=lorenzo.stoakes@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dan.carpenter@linaro.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.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