linux-kernel - Re: [PATCH] arch/microblaze: Added sync method support for DMA and made refinements

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:	Fri, 09 Sep 2011 11:16:57 +0200
From:	Michal Simek <michal.simek@...alogix.com>
To:	Eli Billauer <eli@...lauer.co.il>
CC:	LKML <linux-kernel@...r.kernel.org>, monstr@...str.eu
Subject: Re: [PATCH] arch/microblaze: Added sync method support for DMA  and
 made refinements

Eli Billauer wrote:
> Michal Simek wrote:
> 
>>
>> DMA_TO_DEVICE is fine - data has to be flushed.
>>
>> For DMA_FROM_DEVICE you expect that allocated space will contains data 
>> from device.
>> Which means if you flush them, they will be rewritten by DMA in the 
>> next step.
>> Which means that IMHO you can invalidate them which is faster than 
>> flushing.
> The flushing is only necessary when a certain memory region is written 
> to, not flushed, and then allocated for DMA from device. This is not 
> what drivers usually do, but it's nevertheless legal to do so. Maybe it 
> can also happen as a result of memory being freed but not flushed, and 
> then allocated as a DMA buffer. So this flushing prevents, at most, an 
> extremely rare problem. I don't expect to see something go wrong right 
> away in the lack of this flush.

I prefer to fix the real problems. If you can't see any real problem,
please do not fix theoretical one. I am open to accept your comments
that it is safer to use flush. Look at my second email and add it to 3rd patch.

> 
> In light of this, I can't see why flushing would be slower than 
> invalidation, if the cache lines aren't expected to be dirty except for 
> very rare conditions.

If they are not dirty, flushing/invalidation time should be the same.
But if they are, invalidation is faster.


> 
> As for invalidation of a dirty cache line: Looking at the Microblaze 
> reference manual's description of the wdc instruction, I'm under the 
> impression that each cache line has two flags: Valid and Dirty, as they 
> appear in the pseudocode. I'm not on the clear about what happens if a 
> dirty cache line is invalidated. It would make sense to clear both 
> flags. It also makes sense to write the data back to the RAM in this 
> case. But I really don't know what's actually implemented.

AFAIK if a dirty cache line is invalidated data is just removed from flash
and there is not and you do invalidation - CPU using cache lines(on BE) and writing
data to memory. There could be a lot of stall cycles.

Thanks,
Michal




-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
--
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/