lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 06 Aug 2015 13:40:28 +0200 From: Michal Nazarewicz <mina86@...a86.com> To: Feng Tang <feng.tang@...el.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, John Stultz <john.stultz@...aro.org>, Andrew Morton <akpm@...ux-foundation.org>, Kyungmin Park <kyungmin.park@...sung.com>, Marek Szyprowski <m.szyprowski@...sung.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, linux-kernel@...r.kernel.org Cc: Feng Tang <feng.tang@...el.com> Subject: Re: [PATCH] staging: ion: Add a default struct device for cma heap On Thu, Aug 06 2015, Feng Tang wrote: > When trying to use several cma heaps on our platforms, > we met a memory issue due to that the several cma_heaps > are sharing the same "struct device *". > > As in current code base, the normal cma heap creating > process is, one platform device is created during boot, > and it will sequentially create cma heaps (usually passing > its own struct device * as a parameter) > > For the multiple cma heaps case, there will be one "struct > cma" created for each cma heap, and this "struct cma *" is > saved in dev->cma_area. So the single platform device can't > meet the requirement here. > > So this patch add one default device for a cma heap to avoid > sharing the same "struct device", thus fix the issue. And it > doesn't break existing code by only using that default device > when no "struct device *" is passed in. > > Also, since the cma framework has been cleaned up, this patch > also add a platform data member to pass the "struct cma*" to > ion_cma_heap_create(). > > Signed-off-by: Feng Tang <feng.tang@...el.com> >From CMA’s point of view: Acked-by: Michal Nazarewicz <mina86@...a86.com> > --- > drivers/staging/android/ion/ion.h | 4 ++++ > drivers/staging/android/ion/ion_cma_heap.c | 20 +++++++++++++++++--- > 2 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h > index 443db84..e9af17e 100644 > --- a/drivers/staging/android/ion/ion.h > +++ b/drivers/staging/android/ion/ion.h > @@ -45,6 +45,9 @@ struct ion_buffer; > * @size: size of the heap in bytes if applicable > * @align: required alignment in physical memory if applicable > * @priv: private info passed from the board file > + * @priv2: when creating CMA heap, platform device should better also > + * pass the "struct cma *" info, so that the cma buffer request > + * know where to go for the buffer > * > * Provided by the board file. > */ > @@ -56,6 +59,7 @@ struct ion_platform_heap { > size_t size; > ion_phys_addr_t align; > void *priv; > + void *priv2; Why are those void pointers anyway? Perhaps just make them struct device *dev and struct cma *cma? Especially since priv2 is a bit awkward name. > }; > > /** > diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c > index f4211f1..b3e8896 100644 > --- a/drivers/staging/android/ion/ion_cma_heap.c > +++ b/drivers/staging/android/ion/ion_cma_heap.c > @@ -29,6 +29,7 @@ > struct ion_cma_heap { > struct ion_heap heap; > struct device *dev; > + struct device default_dma_dev; > }; > > #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap) > @@ -180,9 +181,22 @@ struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data) > return ERR_PTR(-ENOMEM); > > cma_heap->heap.ops = &ion_cma_ops; > - /* get device from private heaps data, later it will be > - * used to make the link with reserved CMA memory */ > - cma_heap->dev = data->priv; > + > + /* > + * data->priv for cma heap is currently supposed to point > + * to a "struct device *" > + */ > + if (data->priv) { > + cma_heap->dev = data->priv; > + } else { > + cma_heap->dev = &cma_heap->default_dma_dev; > + cma_heap->dev->coherent_dma_mask = DMA_BIT_MASK(32); > + cma_heap->dev->dma_mask = &dev->coherent_dma_mask; > + } > + > + /* data->priv2 contains a pointer to struct cma */ > + dev_set_cma_area(cma_heap->dev, data->priv2); Perhaps: + if (data->priv2) + dev_set_cma_area(cma_heap->dev, data->priv2); > + > cma_heap->heap.type = ION_HEAP_TYPE_DMA; > return &cma_heap->heap; > } > -- > 1.7.9.5 > -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists