From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: linux-block <linux-block@vger.kernel.org>,
Yi Zhang <yi.zhang@redhat.com>,
"open list:NVM EXPRESS DRIVER" <linux-nvme@lists.infradead.org>,
Hannes Reinecke <hare@suse.de>
Subject: Re: [bug report] kmemleak observed during blktests nvme-tcp
Date: Tue, 2 May 2023 02:35:29 +0000 [thread overview]
Message-ID: <aadcc802-0303-9ffd-ceee-0376ae5aa49e@nvidia.com> (raw)
In-Reply-To: <4f1c6b01-7abe-0599-8249-e3c77072ad61@grimberg.me>
On 5/1/23 01:44, Sagi Grimberg wrote:
>
>
> On 5/1/23 11:23, Chaitanya Kulkarni wrote:
>> On 4/27/23 08:57, Yi Zhang wrote:
>>> On Thu, Apr 27, 2023 at 6:58 PM Chaitanya Kulkarni
>>> <chaitanyak@nvidia.com> wrote:
>>>> On 4/27/23 00:39, Yi Zhang wrote:
>>>>> oops, the kmemleak still exists:
>>>> hmmm, problem is I'm not able to reproduce
>>>> nvme_ctrl_dhchap_secret_store(), I could only get
>>>> cdev ad dev_pm_ops_xxxx. Let's see if following fixes
>>>> nvme_ctrl_dhchap_secret_store() case ? as I've added one
>>>> missing kfree() from earlier fix ..
>>> Hi Chaitanya
>>>
>>> The kmemleak in nvme_ctrl_dhchap_secret_store was fixed with the
>>> change, feel free to add:
>>>
>>> Tested-by: Yi Zhang <yi.zhang@redhat.com>
>>>
>>>
>>
>> I was able to fix remaining memleaks from for blktests
>> nvme/044-nvme/045 with nvme-loop and nvme-tcp transport. I've tested
>> following patch with blktests and memleak on, also specifically tested
>> two testcases in question, whenever you have time see if this fixes all
>> issues, below are the logs from my testing, here is the patch :-
>>
>> linux-block (for-next) # git diff
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 42e90d00fc40..245a832f4df5 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -5151,6 +5151,10 @@ int nvme_init_ctrl(struct nvme_ctrl *ctrl, struct
>> device *dev,
>>
>> BUILD_BUG_ON(NVME_DSM_MAX_RANGES * sizeof(struct
>> nvme_dsm_range) >
>> PAGE_SIZE);
>> + ret = nvme_auth_init_ctrl(ctrl);
>> + if (ret)
>> + return ret;
>> +
>> ctrl->discard_page = alloc_page(GFP_KERNEL);
>> if (!ctrl->discard_page) {
>> ret = -ENOMEM;
>> @@ -5195,13 +5199,8 @@ int nvme_init_ctrl(struct nvme_ctrl *ctrl, struct
>> device *dev,
>>
>> nvme_fault_inject_init(&ctrl->fault_inject,
>> dev_name(ctrl->device));
>> nvme_mpath_init_ctrl(ctrl);
>> - ret = nvme_auth_init_ctrl(ctrl);
>> - if (ret)
>> - goto out_free_cdev;
>
> This does not seem to me like a fix, but a particular way to hide the
> issue.
Agree, but right now Irvin is working on fixing nvme_init_ctrl()
issue(s) and
current block tree has memleak. Shouldn't we fix it before it gets
merged into
the linux/for-next ? if that is not the case we can safely drop this ...
-ck
prev parent reply other threads:[~2023-05-02 2:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 0:37 [bug report] kmemleak observed during blktests nvme-tcp Yi Zhang
2023-04-23 14:15 ` Sagi Grimberg
2023-04-25 9:54 ` Yi Zhang
2023-04-26 8:23 ` Chaitanya Kulkarni
2023-04-26 8:34 ` Chaitanya Kulkarni
2023-04-27 7:24 ` Yi Zhang
2023-04-27 7:39 ` Yi Zhang
2023-04-27 10:58 ` Chaitanya Kulkarni
2023-04-27 15:57 ` Yi Zhang
2023-05-01 8:23 ` Chaitanya Kulkarni
2023-05-01 8:44 ` Sagi Grimberg
2023-05-02 2:35 ` Chaitanya Kulkarni [this message]
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=aadcc802-0303-9ffd-ceee-0376ae5aa49e@nvidia.com \
--to=chaitanyak@nvidia.com \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=yi.zhang@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.