Linux IOMMU Development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Tony Battersby <tonyb@cybernetics.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Tony Lindgren <tony@atomide.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	iommu@lists.linux-foundation.org, Keith Busch <kbusch@kernel.org>,
	kernel-team@fb.com
Subject: Re: [PATCH 08/10] dmapool: cleanup dma_pool_destroy
Date: Tue, 31 May 2022 20:33:23 +0100	[thread overview]
Message-ID: <e5a97b61-6401-8a00-1088-5465a493a556@arm.com> (raw)
In-Reply-To: <30fd23ae-7035-5ce3-5643-89a5956f1e79@cybernetics.com>

On 2022-05-31 19:22, Tony Battersby wrote:
> Remove a small amount of code duplication between dma_pool_destroy() and
> pool_free_page() in preparation for adding more code without having to
> duplicate it.  No functional changes.
> 
> Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
> ---
>   mm/dmapool.c | 34 ++++++++++++++++++++--------------
>   1 file changed, 20 insertions(+), 14 deletions(-)
> 
> diff --git a/mm/dmapool.c b/mm/dmapool.c
> index 8749a9d7927e..58c11dcaa4e4 100644
> --- a/mm/dmapool.c
> +++ b/mm/dmapool.c
> @@ -250,14 +250,25 @@ static inline bool is_page_busy(struct dma_page *page)
>   	return page->in_use != 0;
>   }
>   
> -static void pool_free_page(struct dma_pool *pool, struct dma_page *page)
> +static void pool_free_page(struct dma_pool *pool,
> +			   struct dma_page *page,
> +			   bool destroying_pool)
>   {
> +	void *vaddr = page->vaddr;
>   	dma_addr_t dma = page->dma;
>   
> +	if (destroying_pool && is_page_busy(page)) {
> +		dev_err(pool->dev,
> +			"dma_pool_destroy %s, %p busy\n",
> +			pool->name, vaddr);
> +		/* leak the still-in-use consistent memory */
> +	} else {
>   #ifdef	DMAPOOL_DEBUG
> -	memset(page->vaddr, POOL_POISON_FREED, pool->allocation);
> +		memset(vaddr, POOL_POISON_FREED, pool->allocation);
>   #endif
> -	dma_free_coherent(pool->dev, pool->allocation, page->vaddr, dma);
> +		dma_free_coherent(pool->dev, pool->allocation, vaddr, dma);
> +	}
> +
>   	list_del(&page->page_list);

If we're tearing down the whole pool, surely we can skip this as well? 
(Same for the second list in patch #9)

In fact I think it might make more sense to refactor in the opposite 
direction and just streamline this directly into dma_pool_destroy(), 
more like:

	list_for_each_entry_safe() {
		if (is_page_busy()) {
			dev_err();
		} else {
			dma_free_coherent();
		}
		kfree(page);
	}

>   	kfree(page);
>   }
> @@ -272,7 +283,7 @@ static void pool_free_page(struct dma_pool *pool, struct dma_page *page)
>    */
>   void dma_pool_destroy(struct dma_pool *pool)
>   {
> -	struct dma_page *page, *tmp;
> +	struct dma_page *page;

Nit: you bring this back again in patch #10, so we may as well leave the 
list_for_each_entry_safe() iterator in place until then as well, and 
save a bit of churn in this patch.

>   	bool empty = false;
>   
>   	if (unlikely(!pool))
> @@ -288,15 +299,10 @@ void dma_pool_destroy(struct dma_pool *pool)
>   		device_remove_file(pool->dev, &dev_attr_pools);
>   	mutex_unlock(&pools_reg_lock);
>   
> -	list_for_each_entry_safe(page, tmp, &pool->page_list, page_list) {
> -		if (is_page_busy(page)) {
> -			dev_err(pool->dev, "%s %s, %p busy\n", __func__,
> -				pool->name, page->vaddr);
> -			/* leak the still-in-use consistent memory */
> -			list_del(&page->page_list);
> -			kfree(page);
> -		} else
> -			pool_free_page(pool, page);
> +	while ((page = list_first_entry_or_null(&pool->page_list,
> +						struct dma_page,
> +						page_list))) {
> +		pool_free_page(pool, page, true);
>   	}
>   
>   	kfree(pool);
> @@ -469,7 +475,7 @@ void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma)
>   	page->offset = offset;
>   	/*
>   	 * Resist a temptation to do
> -	 *    if (!is_page_busy(page)) pool_free_page(pool, page);
> +	 *    if (!is_page_busy(page)) pool_free_page(pool, page, false);

Further to the above, even if we did retain a separate function, if an 
argument is hard-coded at the one single callsite, and the only 
reference to passing any other value is in a comment effectively saying 
"don't do this", do we really need to pretend it's an argument at all? ;)

FWIW I'd just reword the comment in more general terms, e.g. "Resist the 
temptation to free unused pages immediately..."

Thanks,
Robin.

>   	 * Better have a few empty pages hang around.
>   	 */
>   	spin_unlock_irqrestore(&pool->lock, flags);
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-05-31 19:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-31 18:11 [PATCH 00/10] mpt3sas and dmapool scalability Tony Battersby
2022-05-31 18:12 ` [PATCH 01/10] dmapool: remove checks for dev == NULL Tony Battersby
2022-05-31 18:23   ` Robin Murphy
2022-05-31 18:13 ` [PATCH 02/10] dmapool: cleanup integer types Tony Battersby
2022-05-31 18:14 ` [PATCH 03/10] dmapool: fix boundary comparison Tony Battersby
2022-05-31 18:17 ` [PATCH 04/10] dmapool: improve accuracy of debug statistics Tony Battersby
2022-05-31 19:48   ` Robin Murphy
2022-05-31 19:52     ` Tony Battersby
2022-05-31 21:55       ` Robin Murphy
2022-05-31 18:18 ` [PATCH 05/10] dmapool: debug: prevent endless loop in case of corruption Tony Battersby
2022-05-31 18:20 ` [PATCH 06/10] dmapool: ignore init_on_free when DMAPOOL_DEBUG enabled Tony Battersby
2022-05-31 18:21 ` [PATCH 07/10] dmapool: speedup DMAPOOL_DEBUG with init_on_alloc Tony Battersby
2022-05-31 18:22 ` [PATCH 08/10] dmapool: cleanup dma_pool_destroy Tony Battersby
2022-05-31 19:33   ` Robin Murphy [this message]
2022-05-31 21:40   ` Keith Busch
2022-05-31 18:23 ` [PATCH 09/10] dmapool: improve scalability of dma_pool_alloc Tony Battersby
2022-05-31 18:23 ` [PATCH 10/10] dmapool: improve scalability of dma_pool_free Tony Battersby
2022-05-31 21:54   ` Keith Busch
2022-05-31 22:10     ` Tony Battersby
2022-06-01  9:44       ` Robin Murphy

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=e5a97b61-6401-8a00-1088-5465a493a556@arm.com \
    --to=robin.murphy@arm.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=kbusch@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony@atomide.com \
    --cc=tonyb@cybernetics.com \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox