mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] regmap: debugfs: fix a memory leak when calling regmap_attach_dev
@ 2020-12-25 12:26 Xiaolei Wang
       [not found] ` <737e8b89-5748-2ef5-5294-8e65421931b9@web.de>
  0 siblings, 1 reply; 3+ messages in thread
From: Xiaolei Wang @ 2020-12-25 12:26 UTC (permalink / raw)
  To: broonie; +Cc: gregkh, rafael, linux-kernel

This should be caused by
commit <9b947a13e7f6> ("<regmap: use debugfs even when no device>")

After initializing the regmap through
syscon_regmap_lookup_by_compatible, then regmap_attach_dev to the
device, because the debugfs_name has been allocated, there is no need to
redistribute it again

unreferenced object 0xd8399b80 (size 64):
  comm "swapper/0", pid 1, jiffies 4294937641 (age 278.590s)
  hex dump (first 32 bytes):
	64 75 6d 6d 79 2d 69 6f 6d 75 78 63 2d 67 70 72
dummy-iomuxc-gpr
	40 32 30 65 34 30 30 30 00 7f 52 5b d8 7e 42 69
@20e4000..R[.~Bi
  backtrace:
	[<ca384d6f>] kasprintf+0x2c/0x54
	[<6ad3bbc2>] regmap_debugfs_init+0xdc/0x2fc
	[<bc4181da>] __regmap_init+0xc38/0xd88
	[<1f7e0609>] of_syscon_register+0x168/0x294
	[<735e8766>] device_node_get_regmap+0x6c/0x98
	[<d96c8982>] imx6ul_init_machine+0x20/0x88
	[<0456565b>] customize_machine+0x1c/0x30
	[<d07393d8>] do_one_initcall+0x80/0x3ac
	[<7e584867>] kernel_init_freeable+0x170/0x1f0
	[<80074741>] kernel_init+0x8/0x120
	[<285d6f28>] ret_from_fork+0x14/0x20
	[<00000000>] 0x0

Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
---
 drivers/base/regmap/regmap-debugfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
index 8dfac7f3ed7a..271142981f98 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -582,8 +582,10 @@ void regmap_debugfs_init(struct regmap *map)
 		devname = dev_name(map->dev);
 
 	if (name) {
-		map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
+		if (!map->debugfs_name) {
+			map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
 					      devname, name);
+		}
 		name = map->debugfs_name;
 	} else {
 		name = devname;
-- 
2.25.1


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

* RE: [PATCH] regmap: debugfs: fix a memory leak when calling regmap_attach_dev
       [not found] ` <737e8b89-5748-2ef5-5294-8e65421931b9@web.de>
@ 2020-12-27 12:18   ` Wang, Xiaolei
       [not found]     ` <46e289a6-49ab-a627-dab1-56a8b0587c08@web.de>
  0 siblings, 1 reply; 3+ messages in thread
From: Wang, Xiaolei @ 2020-12-27 12:18 UTC (permalink / raw)
  To: Markus Elfring, kernel-janitors
  Cc: linux-kernel, Greg Kroah-Hartman, Mark Brown, Rafael J. Wysocki

Hi Markus

> This should be caused by
> commit <9b947a13e7f6> ("<regmap: use debugfs even when no device>")

> I suggest to omit angle brackets from such information.


> * Will another imperative wording become helpful for the commit description?

> * How do you think about to add the tag “Fixes”?

Do you mean so?

commit:
         9b947a13e7f6 ("regmap: use debugfs even when no device")

…
> +++ b/drivers/base/regmap/regmap-debugfs.c
…
> @@ -582,8 +582,10 @@ void regmap_debugfs_init(struct regmap *map)
>  		devname = dev_name(map->dev);
>
>  	if (name) {
> -		map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
> +		if (!map->debugfs_name) {
> +			map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
>  					      devname, name);
> +		}
…

> I propose to add another null pointer check together with corresponding exception handling.

Which one do you mean by "another null point"? Do you mean that if the call "regmap_debugfs_init" function is repeated, it returns directly?

Regards,
Xiaolei



-----Original Message-----
From: Markus Elfring <Markus.Elfring@web.de> 
Sent: Saturday, December 26, 2020 10:16 PM
To: Wang, Xiaolei <Xiaolei.Wang@windriver.com>; kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Mark Brown <broonie@kernel.org>; Rafael J. Wysocki <rafael@kernel.org>
Subject: Re: [PATCH] regmap: debugfs: fix a memory leak when calling regmap_attach_dev

> This should be caused by
> commit <9b947a13e7f6> ("<regmap: use debugfs even when no device>")

I suggest to omit angle brackets from such information.


* Will another imperative wording become helpful for the commit description?

* How do you think about to add the tag “Fixes”?


…
> +++ b/drivers/base/regmap/regmap-debugfs.c
…
> @@ -582,8 +582,10 @@ void regmap_debugfs_init(struct regmap *map)
>  		devname = dev_name(map->dev);
>
>  	if (name) {
> -		map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
> +		if (!map->debugfs_name) {
> +			map->debugfs_name = kasprintf(GFP_KERNEL, "%s-%s",
>  					      devname, name);
> +		}
…

I propose to add another null pointer check together with corresponding exception handling.

Regards,
Markus

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

* RE: regmap: debugfs: fix a memory leak when calling regmap_attach_dev
       [not found]     ` <46e289a6-49ab-a627-dab1-56a8b0587c08@web.de>
@ 2020-12-28  2:26       ` Wang, Xiaolei
  0 siblings, 0 replies; 3+ messages in thread
From: Wang, Xiaolei @ 2020-12-28  2:26 UTC (permalink / raw)
  To: Markus Elfring, kernel-janitors
  Cc: linux-kernel, Greg Kroah-Hartman, Mark Brown, Rafael J. Wysocki

> Do you mean so?
>
> commit:
>          9b947a13e7f6 ("regmap: use debugfs even when no device")

> Please take another look at known information sources.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n89
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n121



> Which one do you mean by "another null point"?

How do you think about to check if calls of the function “kasprintf” succeeded here?
https://elixir.bootlin.com/linux/v5.10.3/source/lib/kasprintf.c#L53

Will any more exception handling become relevant also for the implementation of the function “regmap_debugfs_init”?


-----Original Message-----
From: Markus Elfring <Markus.Elfring@web.de> 
Sent: Sunday, December 27, 2020 9:40 PM
To: Wang, Xiaolei <Xiaolei.Wang@windriver.com>; kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Mark Brown <broonie@kernel.org>; Rafael J. Wysocki <rafael@kernel.org>
Subject: Re: regmap: debugfs: fix a memory leak when calling regmap_attach_dev

> Do you mean so?
>
> commit:
>          9b947a13e7f6 ("regmap: use debugfs even when no device")

> Please take another look at known information sources.

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n89
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=f838f8d2b694cf9d524dc4423e9dd2db13892f3f#n121

> Which one do you mean by "another null point"?

> How do you think about to check if calls of the function “kasprintf” succeeded here?
> https://elixir.bootlin.com/linux/v5.10.3/source/lib/kasprintf.c#L53

> Will any more exception handling become relevant also for the implementation of the function “regmap_debugfs_init”?

Thanks for your suggestion, I will modify the commit log and add another null point check together with corresponding exception handling


Regards,
Xiaolei 

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

end of thread, other threads:[~2020-12-28  2:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-25 12:26 [PATCH] regmap: debugfs: fix a memory leak when calling regmap_attach_dev Xiaolei Wang
     [not found] ` <737e8b89-5748-2ef5-5294-8e65421931b9@web.de>
2020-12-27 12:18   ` Wang, Xiaolei
     [not found]     ` <46e289a6-49ab-a627-dab1-56a8b0587c08@web.de>
2020-12-28  2:26       ` Wang, Xiaolei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®