linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
@ 2022-01-28 14:45 David Hildenbrand
  2022-01-31  5:52 ` Oscar Salvador
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: David Hildenbrand @ 2022-01-28 14:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-mm, David Hildenbrand, stable, Greg Kroah-Hartman,
	Rafael J. Wysocki, Andrew Morton, Michal Hocko, Oscar Salvador

If register_memory() fails, we freed the memory block but already added
the memory block to the group list, not good. Let's defer adding the
block to the memory group to after registering the memory block device.

We do handle it properly during unregister_memory(), but that's not
called when the registration fails.

Fixes: 028fc57a1c36 ("drivers/base/memory: introduce "memory groups" to logically group memory blocks")
Cc: stable@vger.kernel.org # v5.15+
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
 drivers/base/memory.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 365cd4a7f239..60c38f9cf1a7 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -663,14 +663,16 @@ static int init_memory_block(unsigned long block_id, unsigned long state,
 	mem->nr_vmemmap_pages = nr_vmemmap_pages;
 	INIT_LIST_HEAD(&mem->group_next);
 
+	ret = register_memory(mem);
+	if (ret)
+		return ret;
+
 	if (group) {
 		mem->group = group;
 		list_add(&mem->group_next, &group->memory_blocks);
 	}
 
-	ret = register_memory(mem);
-
-	return ret;
+	return 0;
 }
 
 static int add_memory_block(unsigned long base_section_nr)
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
  2022-01-28 14:45 [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded David Hildenbrand
@ 2022-01-31  5:52 ` Oscar Salvador
  2022-02-01  1:01 ` Andrew Morton
  2022-02-01 12:11 ` Michal Hocko
  2 siblings, 0 replies; 6+ messages in thread
From: Oscar Salvador @ 2022-01-31  5:52 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: linux-kernel, linux-mm, stable, Greg Kroah-Hartman,
	Rafael J. Wysocki, Andrew Morton, Michal Hocko

On Fri, Jan 28, 2022 at 03:45:40PM +0100, David Hildenbrand wrote:
> If register_memory() fails, we freed the memory block but already added
> the memory block to the group list, not good. Let's defer adding the
> block to the memory group to after registering the memory block device.
> 
> We do handle it properly during unregister_memory(), but that's not
> called when the registration fails.
> 
> Fixes: 028fc57a1c36 ("drivers/base/memory: introduce "memory groups" to logically group memory blocks")
> Cc: stable@vger.kernel.org # v5.15+
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
  2022-01-28 14:45 [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded David Hildenbrand
  2022-01-31  5:52 ` Oscar Salvador
@ 2022-02-01  1:01 ` Andrew Morton
  2022-02-01  8:16   ` David Hildenbrand
  2022-02-01 12:10   ` Michal Hocko
  2022-02-01 12:11 ` Michal Hocko
  2 siblings, 2 replies; 6+ messages in thread
From: Andrew Morton @ 2022-02-01  1:01 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: linux-kernel, linux-mm, stable, Greg Kroah-Hartman,
	Rafael J. Wysocki, Michal Hocko, Oscar Salvador

On Fri, 28 Jan 2022 15:45:40 +0100 David Hildenbrand <david@redhat.com> wrote:

> If register_memory() fails, we freed the memory block but already added
> the memory block to the group list, not good. Let's defer adding the
> block to the memory group to after registering the memory block device.
> 
> We do handle it properly during unregister_memory(), but that's not
> called when the registration fails.
> 

I guess this has never been known to happen.  So I queued the fix for
5.18-rc1, cc:stable.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
  2022-02-01  1:01 ` Andrew Morton
@ 2022-02-01  8:16   ` David Hildenbrand
  2022-02-01 12:10   ` Michal Hocko
  1 sibling, 0 replies; 6+ messages in thread
From: David Hildenbrand @ 2022-02-01  8:16 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-kernel, linux-mm, stable, Greg Kroah-Hartman,
	Rafael J. Wysocki, Michal Hocko, Oscar Salvador

On 01.02.22 02:01, Andrew Morton wrote:
> On Fri, 28 Jan 2022 15:45:40 +0100 David Hildenbrand <david@redhat.com> wrote:
> 
>> If register_memory() fails, we freed the memory block but already added
>> the memory block to the group list, not good. Let's defer adding the
>> block to the memory group to after registering the memory block device.
>>
>> We do handle it properly during unregister_memory(), but that's not
>> called when the registration fails.
>>
> 
> I guess this has never been known to happen.  So I queued the fix for
> 5.18-rc1, cc:stable.

Triggering that registration error is fairly hard, usually we fail
memory hotplug because we fail to allocate the (largish) memmap. So I am
not aware that this BUG actually triggered.

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
  2022-02-01  1:01 ` Andrew Morton
  2022-02-01  8:16   ` David Hildenbrand
@ 2022-02-01 12:10   ` Michal Hocko
  1 sibling, 0 replies; 6+ messages in thread
From: Michal Hocko @ 2022-02-01 12:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Hildenbrand, linux-kernel, linux-mm, stable,
	Greg Kroah-Hartman, Rafael J. Wysocki, Oscar Salvador

On Mon 31-01-22 17:01:23, Andrew Morton wrote:
> On Fri, 28 Jan 2022 15:45:40 +0100 David Hildenbrand <david@redhat.com> wrote:
> 
> > If register_memory() fails, we freed the memory block but already added
> > the memory block to the group list, not good. Let's defer adding the
> > block to the memory group to after registering the memory block device.
> > 
> > We do handle it properly during unregister_memory(), but that's not
> > called when the registration fails.
> > 
> 
> I guess this has never been known to happen.  So I queued the fix for
> 5.18-rc1, cc:stable.

I do not think this is worth stable backporting. Chances of a failure
are pretty small and I am not aware of any existing report.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded
  2022-01-28 14:45 [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded David Hildenbrand
  2022-01-31  5:52 ` Oscar Salvador
  2022-02-01  1:01 ` Andrew Morton
@ 2022-02-01 12:11 ` Michal Hocko
  2 siblings, 0 replies; 6+ messages in thread
From: Michal Hocko @ 2022-02-01 12:11 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: linux-kernel, linux-mm, stable, Greg Kroah-Hartman,
	Rafael J. Wysocki, Andrew Morton, Oscar Salvador

On Fri 28-01-22 15:45:40, David Hildenbrand wrote:
> If register_memory() fails, we freed the memory block but already added
> the memory block to the group list, not good. Let's defer adding the
> block to the memory group to after registering the memory block device.
> 
> We do handle it properly during unregister_memory(), but that's not
> called when the registration fails.
> 
> Fixes: 028fc57a1c36 ("drivers/base/memory: introduce "memory groups" to logically group memory blocks")
> Cc: stable@vger.kernel.org # v5.15+
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

> ---
>  drivers/base/memory.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 365cd4a7f239..60c38f9cf1a7 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -663,14 +663,16 @@ static int init_memory_block(unsigned long block_id, unsigned long state,
>  	mem->nr_vmemmap_pages = nr_vmemmap_pages;
>  	INIT_LIST_HEAD(&mem->group_next);
>  
> +	ret = register_memory(mem);
> +	if (ret)
> +		return ret;
> +
>  	if (group) {
>  		mem->group = group;
>  		list_add(&mem->group_next, &group->memory_blocks);
>  	}
>  
> -	ret = register_memory(mem);
> -
> -	return ret;
> +	return 0;
>  }
>  
>  static int add_memory_block(unsigned long base_section_nr)
> -- 
> 2.34.1

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-02-01 12:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-28 14:45 [PATCH v1] drivers/base/memory: add memory block to memory group after registration succeeded David Hildenbrand
2022-01-31  5:52 ` Oscar Salvador
2022-02-01  1:01 ` Andrew Morton
2022-02-01  8:16   ` David Hildenbrand
2022-02-01 12:10   ` Michal Hocko
2022-02-01 12:11 ` Michal Hocko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).