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  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:	"" <>
To:	Russell King - ARM Linux <>
CC:	David Laight <David.Laight@...LAB.COM>,
	'Frank Li' <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: RE: [PATCH net-next 5/7] net:fec: add support for dumping transmit
	ring on timeout

From: Russell King - ARM Linux <> Data: Friday, May 30, 2014 8:04 AM
>To: Duan Fugang-B38611
>Cc: David Laight; 'Frank Li'; Li Frank-B20596;;
>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, 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:
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. 

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists