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 for Android: free password hash cracker in your pocket

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

Message-id: <4E60F270.4020208@billauer.co.il>
Date:	Fri, 02 Sep 2011 18:12:48 +0300
From:	Eli Billauer <eli@...lauer.co.il>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	monstr@...str.eu
Subject: Re: [PATCH] arch/microblaze: Added sync method support for DMA  and
 made refinements

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.

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.

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.

Patch with the corrections soon to be posted.

   Eli

-- 
Web: http://www.billauer.co.il

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