All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuai Xue <xueshuai@linux.alibaba.com>
To: Fenghua Yu <fenghuay@nvidia.com>,
	vinicius.gomes@intel.com, dave.jiang@intel.com, vkoul@kernel.org
Cc: nikhil.rao@intel.com, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 7/7] dmaengine: idxd: Refactor remove call with idxd_cleanup() helper
Date: Wed, 19 Feb 2025 21:28:16 +0800	[thread overview]
Message-ID: <5dfdb75c-e532-4a5e-8098-7650c6494d78@linux.alibaba.com> (raw)
In-Reply-To: <4b5b45b3-76a1-4850-aeba-ff4d6777e97c@nvidia.com>



在 2025/2/19 05:01, Fenghua Yu 写道:
> Hi, Shuai,
> 
> On 2/14/25 21:44, Shuai Xue wrote:
>> The idxd_cleanup() helper clean up perfmon, interrupts, internals and so
> 
> s/clean/cleans/
> 
> 
>> on. Refactor remove call with idxd_cleanup() helper to avoid code
> s/idxd_cleanup()/the idxd_cleanup()/
>> duplication. Note, this also fixes the missing put_device() for idxd
>> groups, enginces and wqs.
>>
>> Fixes: bfe1d56091c1 ("dmaengine: idxd: Init and probe for Intel data accelerators")
>> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
>> ---
>>   drivers/dma/idxd/init.c | 13 ++-----------
>>   1 file changed, 2 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
>> index f40f1c44a302..0fbfbe024c29 100644
>> --- a/drivers/dma/idxd/init.c
>> +++ b/drivers/dma/idxd/init.c
>> @@ -1282,20 +1282,11 @@ static void idxd_remove(struct pci_dev *pdev)
>>       get_device(idxd_confdev(idxd));
> get_device() is called here.
>>       device_unregister(idxd_confdev(idxd));
>>       idxd_shutdown(pdev);
>> -    if (device_pasid_enabled(idxd))
>> -        idxd_disable_system_pasid(idxd);
>>       idxd_device_remove_debugfs(idxd);
>> -
>> -    irq_entry = idxd_get_ie(idxd, 0);
>> -    free_irq(irq_entry->vector, irq_entry);
>> -    pci_free_irq_vectors(pdev);
>> +    idxd_cleanup(idxd);
>>       pci_iounmap(pdev, idxd->reg_base);
>> -    if (device_user_pasid_enabled(idxd))
>> -        idxd_disable_sva(pdev);
>> -    pci_disable_device(pdev);
>> -    destroy_workqueue(idxd->wq);
>> -    perfmon_pmu_remove(idxd);
>>       idxd_free(idxd);
> 
> put_device() is called inside idxd_free(). Seems not easy to read code to match the pair.

IMHO, idxd_free() is paired with idxd_alloc() which grap a reference count by
device_initialize(). So, we should match that right pair.

> * When ->release() is called for the idxd->conf_dev, it frees all the memory related
> * to the idxd context.

I did not figure out why you explictly grab reference count of
idxd_confdev(idxd).

idxd_unregister_devices() is paired with idxd_register_devices(), it only
decrease reference through wqs, engines, and groups. So a refcnt of
idxd->conf_dev is still hold by idxd_alloc().

Please correct me, if I missed anything.

> 
> Plus idxd_free() is called only in non FLR case.
> 
> Maybe it's better to change this code to:
> 
> 1. call put_device() outside idxd_free() so that it's easy to match the get_device() and put_deivce in the same level of function.

See my comments above.
> 
> 2. idxd_free() called here is OK because this is not in FLR handler. But only call it in non FLR path in idxd_pci_probe_alloc()
> 

Exactly, so, shoud I add a protection in idxd_free() in a fact that non FLR case will not call it.

Thanks.
Shuai

  reply	other threads:[~2025-02-19 13:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-15  5:44 [PATCH v2 0/7] dmaengine: idxd: fix memory leak in error handling path Shuai Xue
2025-02-15  5:44 ` [PATCH v2 1/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup_wqs Shuai Xue
2025-02-15 11:00   ` [PATCH v2 1/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup_wqs() Markus Elfring
2025-02-16  9:24     ` Shuai Xue
2025-02-16  9:34       ` [v2 " Markus Elfring
2025-02-16 11:04         ` Shuai Xue
2025-02-15 13:34   ` [PATCH v2 1/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup_wqs Markus Elfring
2025-02-16  9:25     ` Shuai Xue
2025-02-18 16:32   ` Fenghua Yu
2025-02-19  9:08     ` Shuai Xue
2025-02-15  5:44 ` [PATCH v2 2/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup_engines Shuai Xue
2025-02-18 20:24   ` Fenghua Yu
2025-02-15  5:44 ` [PATCH v2 3/7] dmaengine: idxd: fix memory leak in error handling path of idxd_setup_groups Shuai Xue
2025-02-18 20:20   ` Fenghua Yu
2025-02-19 11:06     ` Shuai Xue
2025-02-15  5:44 ` [PATCH v2 4/7] dmaengine: idxd: fix memory leak in error handling path of idxd_alloc Shuai Xue
2025-02-15  5:44 ` [PATCH v2 5/7] dmaengine: idxd: fix memory leak in error handling path of idxd_pci_probe Shuai Xue
2025-02-18 20:21   ` Fenghua Yu
2025-02-19 12:28     ` Shuai Xue
2025-02-19 13:05     ` Shuai Xue
2025-02-15  5:44 ` [PATCH v2 6/7] dmaengine: idxd: Add missing idxd cleanup to fix memory leak in remove call Shuai Xue
2025-02-15  5:44 ` [PATCH v2 7/7] dmaengine: idxd: Refactor remove call with idxd_cleanup() helper Shuai Xue
2025-02-18 21:01   ` Fenghua Yu
2025-02-19 13:28     ` Shuai Xue [this message]
2025-03-03  2:01       ` Shuai Xue

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=5dfdb75c-e532-4a5e-8098-7650c6494d78@linux.alibaba.com \
    --to=xueshuai@linux.alibaba.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=fenghuay@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikhil.rao@intel.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vkoul@kernel.org \
    /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.