From: Mike Rapoport <rppt@linux.ibm.com>
To: "Alastair D'Silva" <alastair@au1.ibm.com>
Cc: alastair@d-silva.org, Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Oscar Salvador <osalvador@suse.com>,
Michal Hocko <mhocko@suse.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>,
Wei Yang <richard.weiyang@gmail.com>, Qian Cai <cai@lca.pw>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Jiri Kosina <jkosina@suse.cz>, Mukesh Ojha <mojha@codeaurora.org>,
Arun KS <arunks@codeaurora.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Baoquan He <bhe@redhat.com>,
Logan Gunthorpe <logang@deltatee.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] mm: Trigger bug on if a section is not found in __section_nr
Date: Mon, 17 Jun 2019 09:46:54 +0300 [thread overview]
Message-ID: <20190617064653.GA16810@rapoport-lnx> (raw)
In-Reply-To: <20190617043635.13201-2-alastair@au1.ibm.com>
On Mon, Jun 17, 2019 at 02:36:27PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> If a memory section comes in where the physical address is greater than
> that which is managed by the kernel, this function would not trigger the
> bug and instead return a bogus section number.
>
> This patch tracks whether the section was actually found, and triggers the
> bug if not.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
> mm/sparse.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index fd13166949b5..104a79fedd00 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -105,20 +105,23 @@ static inline int sparse_index_init(unsigned long section_nr, int nid)
> int __section_nr(struct mem_section* ms)
> {
> unsigned long root_nr;
> - struct mem_section *root = NULL;
> + struct mem_section *found = NULL;
> + struct mem_section *root;
>
> for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) {
> root = __nr_to_section(root_nr * SECTIONS_PER_ROOT);
> if (!root)
> continue;
>
> - if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT)))
> - break;
> + if ((ms >= root) && (ms < (root + SECTIONS_PER_ROOT))) {
> + found = root;
> + break;
> + }
> }
>
> - VM_BUG_ON(!root);
> + VM_BUG_ON(!found);
Isn't it enough to check for root_nr == NR_SECTION_ROOTS?
>
> - return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
> + return (root_nr * SECTIONS_PER_ROOT) + (ms - found);
It'll still return a bogus section number with CONFIG_DEBUG_VM=n
> }
> #else
> int __section_nr(struct mem_section* ms)
> --
> 2.21.0
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-06-17 6:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 4:36 [PATCH 0/5] mm: Cleanup & allow modules to hotplug memory Alastair D'Silva
2019-06-17 4:36 ` [PATCH 1/5] mm: Trigger bug on if a section is not found in __section_nr Alastair D'Silva
2019-06-17 6:46 ` Mike Rapoport [this message]
2019-06-17 4:36 ` [PATCH 2/5] mm: don't hide potentially null memmap pointer in sparse_remove_one_section Alastair D'Silva
2019-06-17 6:49 ` Mike Rapoport
2019-06-17 7:26 ` David Hildenbrand
2019-06-17 4:36 ` [PATCH 3/5] mm: Don't manually decrement num_poisoned_pages Alastair D'Silva
2019-06-17 6:52 ` Mike Rapoport
2019-06-17 7:17 ` David Hildenbrand
2019-06-17 4:36 ` [PATCH 4/5] mm/hotplug: Avoid RCU stalls when removing large amounts of memory Alastair D'Silva
2019-06-17 6:53 ` Mike Rapoport
2019-06-17 6:58 ` Alastair D'Silva
2019-06-17 7:47 ` Michal Hocko
2019-06-17 7:57 ` Alastair D'Silva
2019-06-17 8:21 ` Michal Hocko
2019-06-17 15:49 ` Oscar Salvador
2019-06-17 4:36 ` [PATCH 5/5] mm/hotplug: export try_online_node Alastair D'Silva
2019-06-17 6:59 ` Peter Zijlstra
2019-06-17 7:05 ` Alastair D'Silva
2019-06-17 7:15 ` Christoph Hellwig
2019-06-17 8:00 ` Alastair D'Silva
2019-06-17 8:00 ` Alastair D'Silva
2019-06-17 13:14 ` 'Christoph Hellwig'
2019-06-17 7:16 ` Michal Hocko
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=20190617064653.GA16810@rapoport-lnx \
--to=rppt@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alastair@au1.ibm.com \
--cc=alastair@d-silva.org \
--cc=arunks@codeaurora.org \
--cc=bhe@redhat.com \
--cc=cai@lca.pw \
--cc=david@redhat.com \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=logang@deltatee.com \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=mojha@codeaurora.org \
--cc=osalvador@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=peterz@infradead.org \
--cc=richard.weiyang@gmail.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/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.