Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
On Tue, Sep 15, 2020 at 11:15:53AM +0200, David Hildenbrand wrote: >On 15.09.20 11:06, Wei Yang wrote: >> On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: >>> > static int __ref try_remove_memory(int nid, u64 start, u64 size) > { > int rc = 0; > @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 > start, u64 size) > memblock_remove(start, size); > } > > - __release_memory_resource(start, size); > + release_mem_region_adjustable(_resource, start, size); > Seems the only user of release_mem_region_adjustable() is here, can we move iomem_resource into the function body? Actually, we don't iterate the resource tree from any level. We always start from the root. >>> >>> You mean, making iomem_resource implicit? I can spot that something >>> similar was done for >>> >>> #define devm_release_mem_region(dev, start, n) \ >>> __devm_release_region(dev, _resource, (start), (n)) >>> >> >> What I prefer is remove iomem_resource from the parameter list. Just use is >> in >> the function body. >> >> For the example you listed, __release_region() would have varies of *parent*, >> which looks reasonable to keep it here. > >Yeah I got that ("making iomem_resource implicit"), as I said: > Thanks >>> I'll send an addon patch for that, ok? - thanks. > >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me
Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
On 15.09.20 11:06, Wei Yang wrote: > On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: >> static int __ref try_remove_memory(int nid, u64 start, u64 size) { int rc = 0; @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, u64 size) memblock_remove(start, size); } - __release_memory_resource(start, size); + release_mem_region_adjustable(_resource, start, size); >>> >>> Seems the only user of release_mem_region_adjustable() is here, can we move >>> iomem_resource into the function body? Actually, we don't iterate the >>> resource >>> tree from any level. We always start from the root. >> >> You mean, making iomem_resource implicit? I can spot that something >> similar was done for >> >> #define devm_release_mem_region(dev, start, n) \ >> __devm_release_region(dev, _resource, (start), (n)) >> > > What I prefer is remove iomem_resource from the parameter list. Just use is in > the function body. > > For the example you listed, __release_region() would have varies of *parent*, > which looks reasonable to keep it here. Yeah I got that ("making iomem_resource implicit"), as I said: >> I'll send an addon patch for that, ok? - thanks. -- Thanks, David / dhildenb
Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
On Tue, Sep 15, 2020 at 09:35:30AM +0200, David Hildenbrand wrote: > >>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >>> { >>> int rc = 0; >>> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 >>> start, u64 size) >>> memblock_remove(start, size); >>> } >>> >>> - __release_memory_resource(start, size); >>> + release_mem_region_adjustable(_resource, start, size); >>> >> >> Seems the only user of release_mem_region_adjustable() is here, can we move >> iomem_resource into the function body? Actually, we don't iterate the >> resource >> tree from any level. We always start from the root. > >You mean, making iomem_resource implicit? I can spot that something >similar was done for > >#define devm_release_mem_region(dev, start, n) \ > __devm_release_region(dev, _resource, (start), (n)) > What I prefer is remove iomem_resource from the parameter list. Just use is in the function body. For the example you listed, __release_region() would have varies of *parent*, which looks reasonable to keep it here. >I'll send an addon patch for that, ok? - thanks. > >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me
Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
>> static int __ref try_remove_memory(int nid, u64 start, u64 size) >> { >> int rc = 0; >> @@ -1777,7 +1757,7 @@ static int __ref try_remove_memory(int nid, u64 start, >> u64 size) >> memblock_remove(start, size); >> } >> >> -__release_memory_resource(start, size); >> +release_mem_region_adjustable(_resource, start, size); >> > > Seems the only user of release_mem_region_adjustable() is here, can we move > iomem_resource into the function body? Actually, we don't iterate the resource > tree from any level. We always start from the root. You mean, making iomem_resource implicit? I can spot that something similar was done for #define devm_release_mem_region(dev, start, n) \ __devm_release_region(dev, _resource, (start), (n)) I'll send an addon patch for that, ok? - thanks. -- Thanks, David / dhildenb
Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
On Tue, Sep 08, 2020 at 10:10:06PM +0200, David Hildenbrand wrote: >Let's make sure splitting a resource on memory hotunplug will never fail. >This will become more relevant once we merge selected System RAM >resources - then, we'll trigger that case more often on memory hotunplug. > >In general, this function is already unlikely to fail. When we remove >memory, we free up quite a lot of metadata (memmap, page tables, memory >block device, etc.). The only reason it could really fail would be when >injecting allocation errors. > >All other error cases inside release_mem_region_adjustable() seem to be >sanity checks if the function would be abused in different context - >let's add WARN_ON_ONCE() in these cases so we can catch them. > >Cc: Andrew Morton >Cc: Michal Hocko >Cc: Dan Williams >Cc: Jason Gunthorpe >Cc: Kees Cook >Cc: Ard Biesheuvel >Cc: Pankaj Gupta >Cc: Baoquan He >Cc: Wei Yang >Signed-off-by: David Hildenbrand >--- > include/linux/ioport.h | 4 ++-- > kernel/resource.c | 49 -- > mm/memory_hotplug.c| 22 +-- > 3 files changed, 31 insertions(+), 44 deletions(-) > >diff --git a/include/linux/ioport.h b/include/linux/ioport.h >index 6c2b06fe8beb7..52a91f5fa1a36 100644 >--- a/include/linux/ioport.h >+++ b/include/linux/ioport.h >@@ -248,8 +248,8 @@ extern struct resource * __request_region(struct resource >*, > extern void __release_region(struct resource *, resource_size_t, > resource_size_t); > #ifdef CONFIG_MEMORY_HOTREMOVE >-extern int release_mem_region_adjustable(struct resource *, resource_size_t, >- resource_size_t); >+extern void release_mem_region_adjustable(struct resource *, resource_size_t, >+resource_size_t); > #endif > > /* Wrappers for managed devices */ >diff --git a/kernel/resource.c b/kernel/resource.c >index f1175ce93a1d5..36b3552210120 100644 >--- a/kernel/resource.c >+++ b/kernel/resource.c >@@ -1258,21 +1258,28 @@ EXPORT_SYMBOL(__release_region); > * assumes that all children remain in the lower address entry for > * simplicity. Enhance this logic when necessary. > */ >-int release_mem_region_adjustable(struct resource *parent, >-resource_size_t start, resource_size_t size) >+void release_mem_region_adjustable(struct resource *parent, >+ resource_size_t start, resource_size_t size) > { >+ struct resource *new_res = NULL; >+ bool alloc_nofail = false; > struct resource **p; > struct resource *res; >- struct resource *new_res; > resource_size_t end; >- int ret = -EINVAL; > > end = start + size - 1; >- if ((start < parent->start) || (end > parent->end)) >- return ret; >+ if (WARN_ON_ONCE((start < parent->start) || (end > parent->end))) >+ return; > >- /* The alloc_resource() result gets checked later */ >- new_res = alloc_resource(GFP_KERNEL); >+ /* >+ * We free up quite a lot of memory on memory hotunplug (esp., memap), >+ * just before releasing the region. This is highly unlikely to >+ * fail - let's play save and make it never fail as the caller cannot >+ * perform any error handling (e.g., trying to re-add memory will fail >+ * similarly). >+ */ >+retry: >+ new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); > It looks like a bold change, while I don't find a reason to object it. > p = >child; > write_lock(_lock); >@@ -1298,7 +1305,6 @@ int release_mem_region_adjustable(struct resource >*parent, >* so if we are dealing with them, let us just back off here. >*/ > if (!(res->flags & IORESOURCE_SYSRAM)) { >- ret = 0; > break; > } > >@@ -1315,20 +1321,23 @@ int release_mem_region_adjustable(struct resource >*parent, > /* free the whole entry */ > *p = res->sibling; > free_resource(res); >- ret = 0; > } else if (res->start == start && res->end != end) { > /* adjust the start */ >- ret = __adjust_resource(res, end + 1, >- res->end - end); >+ WARN_ON_ONCE(__adjust_resource(res, end + 1, >+ res->end - end)); > } else if (res->start != start && res->end == end) { > /* adjust the end */ >- ret = __adjust_resource(res, res->start, >- start - res->start); >+ WARN_ON_ONCE(__adjust_resource(res, res->start, >+ start - res->start)); >
Re: [PATCH v2 1/7] kernel/resource: make release_mem_region_adjustable() never fail
On Tue, Sep 08, 2020 at 10:10:06PM +0200, David Hildenbrand wrote: >Let's make sure splitting a resource on memory hotunplug will never fail. >This will become more relevant once we merge selected System RAM >resources - then, we'll trigger that case more often on memory hotunplug. > >In general, this function is already unlikely to fail. When we remove >memory, we free up quite a lot of metadata (memmap, page tables, memory >block device, etc.). The only reason it could really fail would be when >injecting allocation errors. > >All other error cases inside release_mem_region_adjustable() seem to be >sanity checks if the function would be abused in different context - >let's add WARN_ON_ONCE() in these cases so we can catch them. > >Cc: Andrew Morton >Cc: Michal Hocko >Cc: Dan Williams >Cc: Jason Gunthorpe >Cc: Kees Cook >Cc: Ard Biesheuvel >Cc: Pankaj Gupta >Cc: Baoquan He >Cc: Wei Yang >Signed-off-by: David Hildenbrand >--- > include/linux/ioport.h | 4 ++-- > kernel/resource.c | 49 -- > mm/memory_hotplug.c| 22 +-- > 3 files changed, 31 insertions(+), 44 deletions(-) > >diff --git a/include/linux/ioport.h b/include/linux/ioport.h >index 6c2b06fe8beb7..52a91f5fa1a36 100644 >--- a/include/linux/ioport.h >+++ b/include/linux/ioport.h >@@ -248,8 +248,8 @@ extern struct resource * __request_region(struct resource >*, > extern void __release_region(struct resource *, resource_size_t, > resource_size_t); > #ifdef CONFIG_MEMORY_HOTREMOVE >-extern int release_mem_region_adjustable(struct resource *, resource_size_t, >- resource_size_t); >+extern void release_mem_region_adjustable(struct resource *, resource_size_t, >+resource_size_t); > #endif > > /* Wrappers for managed devices */ >diff --git a/kernel/resource.c b/kernel/resource.c >index f1175ce93a1d5..36b3552210120 100644 >--- a/kernel/resource.c >+++ b/kernel/resource.c >@@ -1258,21 +1258,28 @@ EXPORT_SYMBOL(__release_region); > * assumes that all children remain in the lower address entry for > * simplicity. Enhance this logic when necessary. > */ >-int release_mem_region_adjustable(struct resource *parent, >-resource_size_t start, resource_size_t size) >+void release_mem_region_adjustable(struct resource *parent, >+ resource_size_t start, resource_size_t size) > { >+ struct resource *new_res = NULL; >+ bool alloc_nofail = false; > struct resource **p; > struct resource *res; >- struct resource *new_res; > resource_size_t end; >- int ret = -EINVAL; > > end = start + size - 1; >- if ((start < parent->start) || (end > parent->end)) >- return ret; >+ if (WARN_ON_ONCE((start < parent->start) || (end > parent->end))) >+ return; > >- /* The alloc_resource() result gets checked later */ >- new_res = alloc_resource(GFP_KERNEL); >+ /* >+ * We free up quite a lot of memory on memory hotunplug (esp., memap), >+ * just before releasing the region. This is highly unlikely to >+ * fail - let's play save and make it never fail as the caller cannot >+ * perform any error handling (e.g., trying to re-add memory will fail >+ * similarly). >+ */ >+retry: >+ new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); > > p = >child; > write_lock(_lock); >@@ -1298,7 +1305,6 @@ int release_mem_region_adjustable(struct resource >*parent, >* so if we are dealing with them, let us just back off here. >*/ > if (!(res->flags & IORESOURCE_SYSRAM)) { >- ret = 0; > break; > } > >@@ -1315,20 +1321,23 @@ int release_mem_region_adjustable(struct resource >*parent, > /* free the whole entry */ > *p = res->sibling; > free_resource(res); >- ret = 0; > } else if (res->start == start && res->end != end) { > /* adjust the start */ >- ret = __adjust_resource(res, end + 1, >- res->end - end); >+ WARN_ON_ONCE(__adjust_resource(res, end + 1, >+ res->end - end)); > } else if (res->start != start && res->end == end) { > /* adjust the end */ >- ret = __adjust_resource(res, res->start, >- start - res->start); >+ WARN_ON_ONCE(__adjust_resource(res, res->start, >+ start - res->start)); > } else { >- /* split into two entries */ >+