From: Jeremy Linton <jeremy.linton@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, cl@linux.com, penberg@kernel.org,
rientjes@google.com, iamjoonsoo.kim@lge.com,
akpm@linux-foundation.org, vbabka@suse.cz, Punit.Agrawal@arm.com,
Lorenzo.Pieralisi@arm.com, linux-arm-kernel@lists.infradead.org,
bhelgaas@google.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/2] mm: harden alloc_pages code paths against bogus nodes
Date: Thu, 2 Aug 2018 22:17:49 -0500 [thread overview]
Message-ID: <5ed35dfa-5f02-55cb-9b84-b944394e1a5a@arm.com> (raw)
In-Reply-To: <20180802073147.GA10808@dhcp22.suse.cz>
Hi,
On 08/02/2018 02:31 AM, Michal Hocko wrote:
> On Wed 01-08-18 15:04:18, Jeremy Linton wrote:
>> Its possible to crash __alloc_pages_nodemask by passing it
>> bogus node ids. This is caused by NODE_DATA() returning null
>> (hopefully) when the requested node is offline. We can
>> harded against the basic case of a mostly valid node, that
>> isn't online by checking for null and failing prepare_alloc_pages.
>>
>> But this then suggests we should also harden NODE_DATA() like this
>>
>> #define NODE_DATA(nid) ( (nid) < MAX_NUMNODES ? node_data[(nid)] : NULL)
>>
>> eventually this starts to add a bunch of generally uneeded checks
>> in some code paths that are called quite frequently.
>
> But the page allocator is really a hot path and people will not be happy
> to have yet another branch there. No code should really use invalid numa
> node ids in the first place.
>
> If I remember those bugs correctly then it was the arch code which was
> doing something wrong. I would prefer that code to be fixed instead.
Yes, I think the consensus is that 2/2 should be dropped.
The arch code is being fixed (both cases) this patch set is just an
attempt to harden this code path against future failures like that so
that we get some warnings/ugly messages rather than early boot failures.
Thanks,
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> include/linux/gfp.h | 2 ++
>> mm/page_alloc.c | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>> index a6afcec53795..17d70271c42e 100644
>> --- a/include/linux/gfp.h
>> +++ b/include/linux/gfp.h
>> @@ -436,6 +436,8 @@ static inline int gfp_zonelist(gfp_t flags)
>> */
>> static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
>> {
>> + if (unlikely(!NODE_DATA(nid))) //VM_WARN_ON?
>> + return NULL;
>> return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
>> }
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index a790ef4be74e..3a3d9ac2662a 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4306,6 +4306,8 @@ static inline bool prepare_alloc_pages(gfp_t gfp_mask, unsigned int order,
>> {
>> ac->high_zoneidx = gfp_zone(gfp_mask);
>> ac->zonelist = node_zonelist(preferred_nid, gfp_mask);
>> + if (!ac->zonelist)
>> + return false;
>> ac->nodemask = nodemask;
>> ac->migratetype = gfpflags_to_migratetype(gfp_mask);
>>
>> --
>> 2.14.3
>>
>
next prev parent reply other threads:[~2018-08-03 3:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-01 20:04 [RFC 0/2] harden alloc_pages against bogus nid Jeremy Linton
2018-08-01 20:04 ` [RFC 1/2] slub: Avoid trying to allocate memory on offline nodes Jeremy Linton
2018-08-02 9:15 ` Michal Hocko
2018-08-03 3:21 ` Jeremy Linton
2018-08-03 6:20 ` Michal Hocko
2018-08-02 14:23 ` Christopher Lameter
2018-08-03 3:12 ` Jeremy Linton
2018-08-01 20:04 ` [RFC 2/2] mm: harden alloc_pages code paths against bogus nodes Jeremy Linton
2018-08-02 7:31 ` Michal Hocko
2018-08-03 3:17 ` Jeremy Linton [this message]
2018-08-03 6:24 ` Michal Hocko
2018-08-01 21:50 ` [RFC 0/2] harden alloc_pages against bogus nid Andrew Morton
2018-08-01 22:56 ` Jeremy Linton
2018-08-02 0:14 ` Andrew Morton
2018-08-03 3:15 ` Jeremy Linton
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=5ed35dfa-5f02-55cb-9b84-b944394e1a5a@arm.com \
--to=jeremy.linton@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Punit.Agrawal@arm.com \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox