From: sashiko-bot@kernel.org
To: "Rik van Riel" <riel@surriel.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"John Hubbard" <jhubbard@nvidia.com>,
"Peter Xu" <peterx@redhat.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Yuan-Hao Hsu" <aa9736195201@gmail.com>,
"Christoph Hellwig" <hch@infradead.org>,
linux-mm@kvack.org
Subject: Re: [PATCH 2/8] mm/gup: convert follow_page_mask() to return a long
Date: Tue, 03 Nov 2026 19:31:49 +0000 [thread overview]
Message-ID: <sashiko-outbox-195920@kernel.org> (raw)
In-Reply-To: <20261102193026.3860700-3-riel@surriel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mm/gup: uninitialized page passed to gup_fill_pages() in __get_user_pages()
--
commit 125cbbdedc195fa32def929c325e903ddc88a720
Author: Rik van Riel <riel@surriel.com>
mm/gup: convert follow_page_mask() to return a long
This commit converts follow_page_mask() and its helpers to return a long
page count or negative errno instead of a struct page pointer, storing the
found page in pages[0].
> diff --git a/mm/gup.c b/mm/gup.c
> index cdbe2ed3e6442..f7d940e7e5ffb 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
[ ... ]
> @@ -1391,6 +1400,7 @@ static long __get_user_pages(struct mm_struct *mm,
> do {
> struct page *page;
> unsigned int page_increm;
> + long nr;
>
> /* first iteration or cross vma bound */
> if (!vma || start >= vma->vm_end) {
> @@ -1417,8 +1427,12 @@ static long __get_user_pages(struct mm_struct *mm,
> pages ? &page : NULL);
> if (ret)
> goto out;
> - page_mask = 0;
> - goto next_page;
> + gup_fill_pages(vma, start, page, 1,
> + pages ? pages + i : NULL);
[Severity: Low]
As reported by Sashiko on RFC v3 [1], does this pass an uninitialized page
pointer to gup_fill_pages() when pages is NULL?
In __get_user_pages(), struct page *page is declared without an initializer
at the start of the loop. When pages is NULL in the gate area path,
get_gate_page() is called with NULL for its page argument and returns 0
without initializing page:
mm/gup.c:get_gate_page() {
...
*vma = get_gate_vma(mm);
if (!page)
goto out;
*page = vm_normal_page(*vma, address, entry);
...
out:
ret = 0;
unmap:
pte_unmap(pte);
return ret;
}
Previously, jumping to next_page guarded the gup_fill_pages() call with
if (pages). Calling gup_fill_pages(vma, start, page, 1, ...) unconditionally
evaluates the uninitialized page variable to pass it by value when pages is
NULL.
[1] https://lore.kernel.org/r/20260811025157.1632867-3-riel@surriel.com
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261102193026.3860700-1-riel@surriel.com?part=2
next prev parent reply other threads:[~2026-11-03 19:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 19:30 [RFC PATCH v5 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-11-02 19:30 ` [PATCH 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-11-03 8:43 ` David Hildenbrand (Arm)
2026-11-03 16:29 ` Rik van Riel
2026-11-03 16:39 ` David Hildenbrand (Arm)
2026-11-03 17:00 ` Rik van Riel
2026-11-03 17:04 ` David Hildenbrand (Arm)
2026-11-03 19:30 ` Rik van Riel
2026-11-05 10:31 ` David Hildenbrand (Arm)
2026-11-02 19:30 ` [PATCH 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-11-03 19:31 ` sashiko-bot [this message]
2026-11-02 19:30 ` [PATCH 3/8] mm/gup: split out folio grab-and-store helper Rik van Riel
2026-11-02 19:30 ` [PATCH 4/8] mm/gup: break out gup_lookup_pte() helper Rik van Riel
2026-11-02 19:30 ` [PATCH 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-11-02 19:30 ` [PATCH 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-11-02 19:30 ` [PATCH 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-11-03 19:31 ` sashiko-bot
2026-11-02 19:30 ` [PATCH 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-11-03 8:35 ` David Hildenbrand (Arm)
2026-11-03 16:42 ` Rik van Riel
2026-11-03 16:55 ` David Hildenbrand (Arm)
2026-11-04 2:08 ` Rik van Riel
2026-11-03 19:31 ` sashiko-bot
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-195920@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aa9736195201@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=hch@infradead.org \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=riel@surriel.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=surenb@google.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.