All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nickolai Zeldovich" <nickolai@csail.mit.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Uladzislau Rezki" <urezki@gmail.com>
Cc: "Baoquan He" <baoquan.he@linux.dev>,
	"Lorenzo Stoakes" <ljs@kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH v1] mm/vmalloc: read vm_map_ram block regions from the requested offset
Date: Sun, 18 Oct 2026 15:41:37 +0000	[thread overview]
Message-ID: <sashiko-outbox-176238@kernel.org> (raw)
In-Reply-To: <20261017154120.795844-1-nickolai@csail.mit.edu>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: off-by-one region size in vmap_ram_vread_iter()
--

commit 5892fe6e95a3367f16e7bc56c39b500d0294baac
Author: Nickolai Zeldovich <nickolai@csail.mit.edu>

mm/vmalloc: read vm_map_ram block regions from the requested offset

This commit updates vmap_ram_vread_iter() to skip vmap_block used regions
that end at or before the current read address and to compute the read
offset relative to the start of the region rather than the page offset.

> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index bea9f76ed7e74..34340c2490b82 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4588,7 +4588,7 @@ static size_t vmap_ram_vread_iter(struct iov_iter *iter, const char *addr,
>  	struct xarray *xa;
>  	unsigned long offset;
>  	unsigned int rs, re;
> -	size_t remains, n;
> +	size_t remains, n, size;
>  
>  	/*
>  	 * If it's area created by vm_map_ram() interface directly, but
> @@ -4622,6 +4622,10 @@ static size_t vmap_ram_vread_iter(struct iov_iter *iter, const char *addr,
>  			goto finished;
>  
>  		start = vmap_block_vaddr(vb->va->va_start, rs);
> +		size = (re - rs + 1) << PAGE_SHIFT;
> +
> +		if (addr >= start + size)
> +			continue;

[Severity: High]
Is size off by one page here?

In include/linux/find.h, for_each_set_bitrange() sets the end index using
find_next_zero_bit():

#define for_each_set_bitrange(b, e, addr, size)			\
	for ((b) = 0;						\
	     (b) = find_next_bit((addr), (size), b),		\
	     (e) = find_next_zero_bit((addr), (size), (b) + 1),	\
	     (b) < (size);					\
	     (b) = (e) + 1)

Because re is the index of the first unset bit after rs (an exclusive upper
bound), the number of allocated pages in the bitrange [rs, re) is (re - rs)
rather than (re - rs + 1).

With size = (re - rs + 1) << PAGE_SHIFT, start + size points one page past
the end of the used region. When read_kcore_iter() -> vread_iter() ->
vmap_ram_vread_iter() reads across the end of a used region or starts at
the first unset page at index re, addr >= start + size does not skip the
preceding region, and page re is passed to aligned_vread_iter() instead of
zero_iter().

In mm/vmalloc.c:vb_free(), vb->used_map is cleared under vb->lock before
vunmap_range_noflush() tears down the PTEs outside the lock:

	spin_lock(&vb->lock);
	bitmap_clear(vb->used_map, offset, (1UL << order));
	spin_unlock(&vb->lock);

	vunmap_range_noflush(addr, addr + size);

Could treating the unset bit at re as part of the used region cause
aligned_vread_iter() to read a page that is concurrently being unmapped and
freed, or read one page past vb->va->va_end when re == VMAP_BBMAP_BITS?

>  
>  		if (addr < start) {
>  			size_t to_zero = min_t(size_t, start - addr, remains);
> @@ -4635,8 +4639,8 @@ static size_t vmap_ram_vread_iter(struct iov_iter *iter, const char *addr,
>  		}
>  
>  		/*it could start reading from the middle of used region*/
> -		offset = offset_in_page(addr);
> -		n = ((re - rs + 1) << PAGE_SHIFT) - offset;
> +		offset = addr - start;
> +		n = size - offset;
>  		if (n > remains)
>  			n = remains;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017154120.795844-1-nickolai@csail.mit.edu?part=1


      parent reply	other threads:[~2026-10-18 15:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17 15:41 [PATCH v1] mm/vmalloc: read vm_map_ram block regions from the requested offset Nickolai Zeldovich
2026-10-17 19:52 ` Andrew Morton
2026-10-17 23:13   ` [PATCH v2] " Nickolai Zeldovich
2026-10-18  9:10     ` Uladzislau Rezki
2026-10-19 12:48       ` Lorenzo Stoakes (ARM)
2026-10-17 23:14   ` [PATCH v1] " Nickolai Zeldovich
2026-10-18 15:41 ` sashiko-bot [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=sashiko-outbox-176238@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baoquan.he@linux.dev \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=nickolai@csail.mit.edu \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=urezki@gmail.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.