From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Pavel Tatashin <pasha.tatashin@soleen.com>, Qian Cai <cai@lca.pw>,
Wei Yang <richard.weiyang@gmail.com>,
Arun KS <arunks@codeaurora.org>,
Mathieu Malaterre <malat@debian.org>
Subject: Re: [PATCH v1 3/4] mm/memory_hotplug: Make __remove_section() never fail
Date: Wed, 17 Apr 2019 15:56:18 +0200 [thread overview]
Message-ID: <1555509378.3139.35.camel@suse.de> (raw)
In-Reply-To: <20190409100148.24703-4-david@redhat.com>
On Tue, 2019-04-09 at 12:01 +0200, David Hildenbrand wrote:
> Let's just warn in case a section is not valid instead of failing to
> remove somewhere in the middle of the process, returning an error
> that
> will be mostly ignored by callers.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
> Cc: Qian Cai <cai@lca.pw>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Arun KS <arunks@codeaurora.org>
> Cc: Mathieu Malaterre <malat@debian.org>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Just a nit:
I think this could be combined with patch#2.
The only reason to fail in here is 1) !valid_section 2)
!present_section.
As I stated in patch#2, one cannot be without the other, so makes sense
to rip present_section check from unregister_mem_section() as well.
Then, you could combine both changelogs explaining the whole thing, and
why we do not need the present_section check either.
But the change looks good to me:
Reviewed-by: Oscar Salvador <osalvador@suse.de>
> ---
> mm/memory_hotplug.c | 22 +++++++++-------------
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index b0cb05748f99..17a60281c36f 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -517,15 +517,15 @@ static void __remove_zone(struct zone *zone,
> unsigned long start_pfn)
> pgdat_resize_unlock(zone->zone_pgdat, &flags);
> }
>
> -static int __remove_section(struct zone *zone, struct mem_section
> *ms,
> - unsigned long map_offset, struct vmem_altmap
> *altmap)
> +static void __remove_section(struct zone *zone, struct mem_section
> *ms,
> + unsigned long map_offset,
> + struct vmem_altmap *altmap)
> {
> unsigned long start_pfn;
> int scn_nr;
> - int ret = -EINVAL;
>
> - if (!valid_section(ms))
> - return ret;
> + if (WARN_ON_ONCE(!valid_section(ms)))
> + return;
>
> unregister_memory_section(ms);
>
> @@ -534,7 +534,6 @@ static int __remove_section(struct zone *zone,
> struct mem_section *ms,
> __remove_zone(zone, start_pfn);
>
> sparse_remove_one_section(zone, ms, map_offset, altmap);
> - return 0;
> }
>
> /**
> @@ -554,7 +553,7 @@ int __remove_pages(struct zone *zone, unsigned
> long phys_start_pfn,
> {
> unsigned long i;
> unsigned long map_offset = 0;
> - int sections_to_remove, ret = 0;
> + int sections_to_remove;
>
> /* In the ZONE_DEVICE case device driver owns the memory
> region */
> if (is_dev_zone(zone)) {
> @@ -575,16 +574,13 @@ int __remove_pages(struct zone *zone, unsigned
> long phys_start_pfn,
> unsigned long pfn = phys_start_pfn +
> i*PAGES_PER_SECTION;
>
> cond_resched();
> - ret = __remove_section(zone, __pfn_to_section(pfn),
> map_offset,
> - altmap);
> + __remove_section(zone, __pfn_to_section(pfn),
> map_offset,
> + altmap);
> map_offset = 0;
> - if (ret)
> - break;
> }
>
> set_zone_contiguous(zone);
> -
> - return ret;
> + return 0;
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2019-04-17 13:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 10:01 [PATCH v1 0/4] mm/memory_hotplug: Better error handling when removing memory David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory() David Hildenbrand
2019-04-09 22:41 ` Andrew Morton
2019-04-10 8:07 ` David Hildenbrand
2019-04-17 3:37 ` Andrew Morton
2019-04-17 7:44 ` David Hildenbrand
2019-04-17 11:52 ` Oscar Salvador
2019-04-17 12:02 ` [PATCH] mm/memory_hotplug: Fixup "Release memory resource after arch_remove_memory()" David Hildenbrand
2019-04-17 13:12 ` [PATCH v1 1/4] mm/memory_hotplug: Release memory resource after arch_remove_memory() Michal Hocko
2019-04-17 13:24 ` David Hildenbrand
2019-04-17 13:31 ` Michal Hocko
2019-04-17 13:48 ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 2/4] mm/memory_hotplug: Make unregister_memory_section() never fail David Hildenbrand
2019-04-17 12:45 ` Oscar Salvador
2019-04-17 13:10 ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 3/4] mm/memory_hotplug: Make __remove_section() " David Hildenbrand
2019-04-17 13:56 ` Oscar Salvador [this message]
2019-04-24 6:54 ` David Hildenbrand
2019-04-09 10:01 ` [PATCH v1 4/4] mm/memory_hotplug: Make __remove_pages() and arch_remove_memory() " David Hildenbrand
2019-04-09 10:01 ` David Hildenbrand
2019-04-09 10:01 ` David Hildenbrand
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=1555509378.3139.35.camel@suse.de \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=arunks@codeaurora.org \
--cc=cai@lca.pw \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=malat@debian.org \
--cc=mhocko@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=richard.weiyang@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.