All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: Olivier Dautricourt <olivier.dautricourt@orolia.com>
Cc: Vinod Koul <vkoul@kernel.org>, dmaengine@vger.kernel.org
Subject: Re: Possible bug when using dmam_alloc_coherent in conjonction with of_reserved_mem_device_release
Date: Sat, 22 May 2021 11:28:52 +0100	[thread overview]
Message-ID: <4S7ITQ.ORCLYUEJD8BH3@crapouillou.net> (raw)
In-Reply-To: <YKf4zlklLdfJBN6p@orolia.com>

Hi Olivier,


Le ven., mai 21 2021 at 20:15:42 +0200, Olivier Dautricourt 
<olivier.dautricourt@orolia.com> a écrit :
> Hello all,
> 
> I am facing a problem when using dmam_alloc_coherent (the managed
> version of dma_alloc_coherent) along with a device-specific reserved 
> memory
> region using the CMA.
> 
> My observation is on a kernel 5.10.19 (arm), as i'm unable to test 
> the exact
> same configuration on a newer kernel. However it seems that the 
> relevent code
> did not change too much since, so i think it's still applicable.
> 
> 
> ....
> The issue:
> 
> I declare a reserved region on my board such as:
> 
> mydevice_reserved: linux,cma {
>         compatible = "shared-dma-pool";
>         reusable;
>         size = <0x2400000>;
> };
> 
> and start the kernel with cma=0, i want my region to be reserved to 
> my device.
> 
> My driver basically does:
> 
> probe(dev):
> 	of_reserved_mem_device_init(dev)
> 	dmam_alloc_coherent(...)
> 
> release(dev):
> 	of_reserved_mem_device_release(dev)

You must make sure that whatever is allocated or initialized is freed 
or deinitialized in the reverse order, which is not what will happen 
here: release(dev) will be called before the dev-managed cleanups.

To fix your issue, either use dma_alloc_coherent() and call 
dma_free_coherent() in release(), or register 
of_reserved_mem_device_release() as a dev-managed cleanup function 
(which is what my driver does).

Cheers,
-Paul

> On driver detach, of_reserved_mem_device_release will call
> rmem_cma_device_release which sets dev->cma_area = NULL;
> Then the manager will try to free the dma memory allocated in the 
> probe:
> 
> __free_from_contiguous -> dma_release_from_contiguous ->
> cma_release(dev_get_cma_area(dev), ...);
> 
> Except that now dev_get_cma_area will return 
> dma_contiguous_default_area
> which is null in my setup:
> 
> static inline struct cma *dev_get_cma_area(struct device *dev)
> {
> 	if (dev && dev->cma_area) // dev->cma_area is null
> 		return dev->cma_area;
> 
> 	return dma_contiguous_default_area; // null in my setup
> }
> 
> and so cma_release will do nothing.
> 
> bool cma_release(struct cma *cma, const struct page *pages, unsigned 
> int count)
> {
> 	unsigned long pfn;
> 
> 	if (!cma || !pages) // cma is NULL
> 		return false;
> 
> __free_from_contiguous will fail silently because it ignores
> dma_release_from_contiguous boolean result.
> 
> The driver will be unable to load and allocate memory again because 
> the
> area allocated with dmam_alloc_coherent is not freed.
> ...
> 
> So i started to look at drivers using both dmam_alloc_coherent and
> of_reserved_mem_device_release and found this driver:
> (gpu/drm/ingenic/ingenic-drm-drv.c).
> This is why i included the original author, Paul Cercueil, in the 
> loop.
> 
> Q:
> 
> I noticed that Paul used devm_add_action_or_reset to trigger
> of_reserved_mem_device_release on driver detach, is this because of 
> this
> problem that we use a devm trigger here ?
> 
> I tried to do the same in my driver, but rmem_cma_device_release is 
> still
> called before dmam_release, is there a way to force the order ?
> 
> Is what i described a bug that needs fixing ?
> 
> 
> Thank you,
> 
> 
> Olivier
> 
> 



  reply	other threads:[~2021-05-22 10:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 18:15 Possible bug when using dmam_alloc_coherent in conjonction with of_reserved_mem_device_release Olivier Dautricourt
2021-05-22 10:28 ` Paul Cercueil [this message]
2021-05-22 11:42   ` Olivier Dautricourt
2021-05-22 12:31     ` Paul Cercueil
2021-05-22 13:09       ` Olivier Dautricourt

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=4S7ITQ.ORCLYUEJD8BH3@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=olivier.dautricourt@orolia.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.