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]

Message-ID: <20150731151816.GA18347@shbuild888>
Date:	Fri, 31 Jul 2015 23:18:16 +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>
Subject: Re: [PATCH] CMA: Don't return a valid cma for non-cma dev

On Fri, Jul 31, 2015 at 02:05:17PM +0200, Michal Nazarewicz wrote:
> On Fri, Jul 31 2015, Feng Tang wrote:
> > Hi Michal Nazarewicz,
> >
> > Thanks for the review.
> >
> > On Thu, 2015-07-30 at 15:59 +0200, Michal Nazarewicz wrote:
> >> On Thu, Jul 30 2015, Feng Tang wrote:
> >> > When system(one x86 soc) boot, we saw many normal dma allocation requests
> >> > goes to cma area. The call chain is
> >> > 	dma_generic_alloc_coherent
> >> > 	    dma_alloc_from_contiguous	-- arch/x86/kernel/pci-dma.c
> >> > 	        cma_alloc(dev_get_cma_area(dev), count, align)
> >> >
> >> > Current dev_get_cma_area() will return a valid "cma" anyway. Then all
> >> > these requests will be taken as valid cma request, and get pages from
> >> > cma area, which has 2 problems:
> >> > 1. make the cma area fragmented
> >> > 2. confuse the cma reservation, usually cma memory size is set according
> >> >    to the expectation of system scenario, these unexpected requests
> >> >    will affect the designed cma usage.
> >> >
> >> > So this patch will enforce the judgement, and only return valid "cma"
> >> > for real cma user, thus make normal user like IO device driver not
> >> > abuse cma reserved region.
> >> 
> >> Just don’t set dma_contiguous_default_area.  This patch defeats the
> >> purpose of a *default* area.
> >
> > Yes! This is exactly what I tried when I first saw this problem, but
> > this failed as there 2 places inside drivers/base/dma-contiguous.c
> > which set the dma_contiguous_default_area
> >
> > 1) 
> > void __init dma_contiguous_reserve(phys_addr_t limit)
> > {
> >     ....
> >     dma_contiguous_reserve_area(selected_size, selected_base,
> >                                             selected_limit,
> >                                    &dma_contiguous_default_area,
> >                                             fixed);
> >      ....
> > }
> >
> > 2) 
> > static int __init rmem_cma_setup(struct reserved_mem *rmem)
> > {
> >     ...
> >     if (of_get_flat_dt_prop(node, "linux,cma-default", NULL))
> >                 dma_contiguous_set_default(cma);
> >     ...
> > }
> >
> > Are you suggesting me to remove them?
> 
> Set CONFIG_CMA_SIZE_MBYTES to zero (in Kconfig) or add ‘cma=0’ on
> command line, and don’t use ‘linux,cma-default’ in device tree.  Then
> you will end up with no default CMA area.

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".

The current situation is we have 2 kinds of request to call 
dma_alloc_from_contiguous():
1. Those general IO drivers like spi/i2c/emmc/audio which will
request 1 to dozen of pages for normal DMA use 
2. The camera ISP and other HW which needs from seveal MB to 
 20MB CMA buffer, total CMA number may reach 180MB or more

We don't want the 1st customers to go into CMA area, to fragment
the CMA area from time to time. That's why I finally came up
with this patch.

Any suggestions?

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/