From: Andrew Morton <akpm@linux-foundation.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Mel Gorman <mgorman@techsingularity.net>,
Alexander Lobakin <alobakin@pm.me>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: __alloc_pages_bulk(): do bounds check before accessing array
Date: Tue, 22 Jun 2021 21:49:22 -0700 [thread overview]
Message-ID: <20210622214922.fbf7ce7eb2864292d91ca4f2@linux-foundation.org> (raw)
In-Reply-To: <387ca68d-7c59-b316-7d95-cf13a3b26770@rasmusvillemoes.dk>
On Mon, 21 Jun 2021 18:01:17 +0200 Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> On 07/05/2021 12.26, Mel Gorman wrote:
> > On Fri, May 07, 2021 at 08:45:03AM +0200, Rasmus Villemoes wrote:
> >> In the event that somebody would call this with an already fully
> >> populated page_array, the last loop iteration would do an access
> >> beyond the end of page_array.
> >>
> >> It's of course extremely unlikely that would ever be done, but this
> >> triggers my internal static analyzer. Also, if it really is not
> >> supposed to be invoked this way (i.e., with no NULL entries in
> >> page_array), the nr_populated<nr_pages check could simply be removed
> >> instead.
> >>
> >> Fixes: 0f87d9d30f21 (mm/page_alloc: add an array-based interface to the bulk page allocator)
> >> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> >
> > Acked-by: Mel Gorman <mgorman@techsingularity.net>
> >
>
> Andrew, will you get this to Linus before 5.13 is released? I got a mail
> on May 9 that it had been added to your queue, but I don't see it in
> master yet.
I had it queued for 5.14-rc1.
I'll move it into the 5.13 queue as it fixes a post-5.12 thing, but
nothing in the changelog indicates that it's at all urgent? Was the
changelog missing some important info?
: In the event that somebody would call this with an already fully populated
: page_array, the last loop iteration would do an access beyond the end of
: page_array.
:
: It's of course extremely unlikely that would ever be done, but this
: triggers my internal static analyzer. Also, if it really is not supposed
: to be invoked this way (i.e., with no NULL entries in page_array), the
: nr_populated<nr_pages check could simply be removed instead.
prev parent reply other threads:[~2021-06-23 4:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 6:45 [PATCH] mm/page_alloc: __alloc_pages_bulk(): do bounds check before accessing array Rasmus Villemoes
2021-05-07 10:26 ` Mel Gorman
2021-06-21 16:01 ` Rasmus Villemoes
2021-06-23 4:49 ` Andrew Morton [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=20210622214922.fbf7ce7eb2864292d91ca4f2@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=alobakin@pm.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mgorman@techsingularity.net \
--cc=vbabka@suse.cz \
/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.