mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>
To: Ira Weiny <ira.weiny@intel.com>,
	"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>
Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
	"dave.jiang@intel.com" <dave.jiang@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] nvdimm: Fix devs leaks in scan_labels()
Date: Mon, 29 Jul 2024 02:32:59 +0000	[thread overview]
Message-ID: <7ccc9770-b7e0-4657-a4f6-7c49c3e20866@fujitsu.com> (raw)
In-Reply-To: <66a3a6b2292cc_1bcf5d29459@iweiny-mobl.notmuch>



On 26/07/2024 21:37, Ira Weiny wrote:
> Li Zhijian wrote:
>> The leakage would happend when create_namespace_pmem() meets an invalid
>> label which gets failure in validating isetcookie.
>>
>> Try to resuse the devs that may have already been allocated with size
>> (2 * sizeof(dev)) previously.
>>
>> A kmemleak reports:
>> unreferenced object 0xffff88800dda1980 (size 16):
>>    comm "kworker/u10:5", pid 69, jiffies 4294671781
>>    hex dump (first 16 bytes):
>>      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>    backtrace (crc 0):
>>      [<00000000c5dea560>] __kmalloc+0x32c/0x470
>>      [<000000009ed43c83>] nd_region_register_namespaces+0x6fb/0x1120 [libnvdimm]
>>      [<000000000e07a65c>] nd_region_probe+0xfe/0x210 [libnvdimm]
>>      [<000000007b79ce5f>] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm]
>>      [<00000000a5f3da2e>] really_probe+0xc6/0x390
>>      [<00000000129e2a69>] __driver_probe_device+0x78/0x150
>>      [<000000002dfed28b>] driver_probe_device+0x1e/0x90
>>      [<00000000e7048de2>] __device_attach_driver+0x85/0x110
>>      [<0000000032dca295>] bus_for_each_drv+0x85/0xe0
>>      [<00000000391c5a7d>] __device_attach+0xbe/0x1e0
>>      [<0000000026dabec0>] bus_probe_device+0x94/0xb0
>>      [<00000000c590d936>] device_add+0x656/0x870
>>      [<000000003d69bfaa>] nd_async_device_register+0xe/0x50 [libnvdimm]
>>      [<000000003f4c52a4>] async_run_entry_fn+0x2e/0x110
>>      [<00000000e201f4b0>] process_one_work+0x1ee/0x600
>>      [<000000006d90d5a9>] worker_thread+0x183/0x350
>>
>> Cc: Dave Jiang <dave.jiang@intel.com>
>> Cc: Ira Weiny <ira.weiny@intel.com>
>> Fixes: 1b40e09a1232 ("libnvdimm: blk labels and namespace instantiation")
> 
> What is the bigger effect the user will see?

*Users* cannot use this pmem until they zero-label the device.
In my understanding, once the leakage occurs, there is no way to reclaim the memory until reboot


> 
> Does this cause a long term user effect?  For example, if a users system
> has a bad label I think this is going to be a pretty minor memory leak
> which just hangs around until reboot, correct?
> 
>> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
>> ---
>>
>> Cc: Ira Weiny <ira.weiny@intel.com>
>>>  From what I can tell create_namespace_pmem() must be returning EAGAIN
>>> which leaves devs allocated but fails to increment count.  Thus there are
>>> no valid labels but devs was not free'ed.
>>
>>> Can you trace the error you are seeing a bit more to see if this is the
>>> case?
>>    Hi Ira, Sorry for the late reply. I have reproduced it these days.
>>    Yeah, the LSA is containing a label in which the isetcookie is invalid.
> 
> NP, sometimes it takes a while to really debug something.
> 
>>
>> V2:
>>    update description and comment
>> ---
>>   drivers/nvdimm/namespace_devs.c | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
>> index d6d558f94d6b..28c9afc01dca 100644
>> --- a/drivers/nvdimm/namespace_devs.c
>> +++ b/drivers/nvdimm/namespace_devs.c
>> @@ -1994,7 +1994,13 @@ static struct device **scan_labels(struct nd_region *nd_region)
>>   		/* Publish a zero-sized namespace for userspace to configure. */
>>   		nd_mapping_free_labels(nd_mapping);
>>   
>> -		devs = kcalloc(2, sizeof(dev), GFP_KERNEL);
>> +		/*
>> +		 * Try to use the devs that may have already been allocated
>> +		 * above first. This would happend when create_namespace_pmem()
>> +		 * meets an invalid label.
>> +		 */
>> +		if (!devs)
>> +			devs = kcalloc(2, sizeof(dev), GFP_KERNEL);
> 
> I'm still tempted to try and fix the count but I think this will work.

I cannot get your *fix the count* ?
Does "fix the count*" means to free the devs in the case of error cases:

$ git diff
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 28c9afc01dca..3fae00a05ad7 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1970,6 +1970,10 @@ static struct device **scan_labels(struct nd_region *nd_region)
  
                 dev = create_namespace_pmem(nd_region, nd_mapping, nd_label);
                 if (IS_ERR(dev)) {
+                       if (!count) {
+                               kfree(devs);
+                               devs = NULL;
+                       }





> Let me know about the severity of the issue.
> 
> Ira
> 
>>   		if (!devs)
>>   			goto err;
>>   
>> -- 
>> 2.29.2
>>
> 
> 
> 

  reply	other threads:[~2024-07-29  2:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-19  1:58 Li Zhijian
2024-07-19  1:58 ` [PATCH v2 2/2] nvdimm: Remove dead code for ENODEV checking " Li Zhijian
2024-07-26 13:37 ` [PATCH v2 1/2] nvdimm: Fix devs leaks " Ira Weiny
2024-07-29  2:32   ` Zhijian Li (Fujitsu) [this message]
2024-08-09 22:38 ` Dan Williams
2024-08-09 22:55   ` Dan Williams
2024-08-19  6:04     ` Zhijian Li (Fujitsu)
2024-08-19  3:45   ` Zhijian Li (Fujitsu)

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=7ccc9770-b7e0-4657-a4f6-7c49c3e20866@fujitsu.com \
    --to=lizhijian@fujitsu.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=vishal.l.verma@intel.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 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®