linux-kernel - Re: [PATCH] CMA: Don't return a valid cma for non-cma dev

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Aug 2015 17:19:17 +0800
From:	Feng Tang <feng.tang@...el.com>
To:	Michal Nazarewicz <mina86@...a86.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>
Subject: Re: [PATCH] CMA: Don't return a valid cma for non-cma dev

On Fri, Jul 31, 2015 at 07:46:30PM +0200, Michal Nazarewicz wrote:
> On Fri, Jul 31 2015, Feng Tang wrote:
> > Maybe I didn't make my problem clear, for our platform, we do need to
> > use cma as we have camera ISP which has no IOMMU, so we cannot set
> > "cma=0".
> 
> Then specify a CMA region for the camera in platform initialisation code
> or device trees or whatever else is the rave nowadays.
> 
> I’m assuming that you have a piece of code (or configuration of some
> sort) that assigns a CMA region to the device (otherwise ‘dev->cma_area’
> would be NULL and your patch would just always get you NULL CMA area).
> Simply create a CMA area there and assign it to the device.

Your suggestion remind me one more thing, that for a system which needs
multiple cma heaps (like for security reason), they may have to share
one struct device *dev, as in ion_cma_heap_create()

struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
{
	struct ion_cma_heap *cma_heap;

	cma_heap = kzalloc(sizeof(struct ion_cma_heap), GFP_KERNEL);

	if (!cma_heap)
		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;
	cma_heap->heap.type = ION_HEAP_TYPE_DMA;
	return &cma_heap->heap;
}

Usually the platform data's priv points to the same ion platform device,
so the several heap's dev will be same.

Then when the time comes to allocate for each cma heap, the "dev->cma_area"
may have to be dynamically switched, and casue many syncing trouble.

I'm working on a patch for this. 

Thanks,
Feng


--
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/