netdev - RE: [PATCH net-next 5/7] net:fec: add support for dumping transmit ring on timeout

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] [day] [month] [year] [list]

Date:	Fri, 30 May 2014 01:51:17 +0000
From:	"fugang.duan@...escale.com" <fugang.duan@...escale.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	David Laight <David.Laight@...LAB.COM>,
	'Frank Li' <lznuaa@...il.com>,
	"Frank.Li@...escale.com" <Frank.Li@...escale.com>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 5/7] net:fec: add support for dumping transmit
	ring on timeout

From: Russell King - ARM Linux <linux@....linux.org.uk> Data: Friday, May 30, 2014 8:04 AM
>To: Duan Fugang-B38611
>Cc: David Laight; 'Frank Li'; Li Frank-B20596; shawn.guo@...aro.org;
>davem@...emloft.net; netdev@...r.kernel.org
>Subject: Re: [PATCH net-next 5/7] net:fec: add support for dumping
>transmit ring on timeout
>
>On Thu, May 29, 2014 at 08:17:07AM +0000, fugang.duan@...escale.com wrote:
>> Hi, Russell,
>>
>> I see linux next and net "imx_v6_v7_defconfig" don't enable
>> "CONFIG_CMA", if you enable the feature,
>
>Sorry, telling people that CMA is required to avoid that is just not an
>acceptable "solution".
>
>With CMA not enabled, the DMA memory provided to the driver is still
>perfectly valid and should be no different from what CMA provides.
>
>I'd strongly suggest investigating why there is this difference, and what
>the difference is - I'd assume freescale have the ability to do that with
>their own devices much more than I have, and probably to a greater depth
>too - especially as there is no possibility what so ever of using any kind
>of hardware debug on the iMX6 platforms I have.
>
I accept your suggestion to inverstigate the difference. Thanks.
Can you take some time to glance over the attached document by previous mail, we indeed did some tests/analyze on the issue.
Because the DMA memory coherent issue happened at fec, usb, audio modules.

>From the CMA article: http://lwn.net/Articles/450286/:
If a region of low memory is turned into a DMA buffer with an uncached mapping, the system will have two conflicting mappings for the same memory and will have moved into "undefined behavior" territory.

For imx6 DMA memory mapping:
One physical mapping for lowmem map: cacheable with allocate
The physical another mapping for DMA zone remap: Non-cacheable bufferable (kernel with CONFIG_ARM_DMA_MEM_BUFFERABLE enable)

According to the PL301 L2 Cache Controller TRM, memory with normal memory type, shared, outer-non-cacheable attribute can be treated as cacheable memory:
    - Non-cacheable shared reads are treated as cacheable non-allocatable.
    - Non-cacheable shared writes are treated as cacheable write-through no write-allocate. 
Since the access is treated as non-allocate, if the memory is not cached in the L2, the read/write access will always go to the L3 memory. So most of the time, there is no issue with this feature. 

But when there are multiple virtual addresses mapping to same physical address, and if one of the virtual address has a real "cacheable" attribute, this feature would cause us trouble. 

Thanks,
Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html