lkml.org 
[lkml]   [2022]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] drivers/base/memory: Fix a reference counting issue in __add_memory_block()
On Fri 22-04-22 09:15:21, Christophe JAILLET wrote:
> There is no point in doing put_device()/device_unregister() on a
> device that has just been registered a few lines above. This will lead to
> a double reference decrement.

This is a bit confusing. I would rephrase.
"
__add_memory_block calls both put_device and device_unregister when
storing the memory block into the xarray. This is incorrect because
xarray doesn't take an additional reference and device_unregister
already calls put_device.
"

Btw. I do not think this failure path can be triggered, or is there a
way to hit it?

> I guess that this put_device()/device_unregister() is a cut'n'paste from
> remove_memory_block() (i.e. unregister_memory() at the time being) which
> does need it.
>
> Fixes: 4fb6eabf1037 ("drivers/base/memory.c: cache memory blocks in xarray to accelerate lookup")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Other than that looks good to me. With the changelog clarified,
especially the part that evaluates whether this is a real or a
theoretical problem, feel free to add
Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

> ---
> drivers/base/memory.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 7222ff9b5e05..084d67fd55cc 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -636,10 +636,9 @@ static int __add_memory_block(struct memory_block *memory)
> }
> ret = xa_err(xa_store(&memory_blocks, memory->dev.id, memory,
> GFP_KERNEL));
> - if (ret) {
> - put_device(&memory->dev);
> + if (ret)
> device_unregister(&memory->dev);
> - }
> +
> return ret;
> }
>
> --
> 2.32.0

--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2022-04-22 09:36    [W:0.039 / U:3.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site