netdev - Re: [PATCH 002/002] de2104x: support for systems lacking cache coherence

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: <20090209.145156.172588416.davem@davemloft.net>
Date:	Mon, 09 Feb 2009 14:51:56 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	risto.suominen@...il.com
Cc:	khc@...waw.pl, netdev@...r.kernel.org
Subject: Re: [PATCH 002/002] de2104x: support for systems lacking cache
 coherence

From: Risto Suominen <risto.suominen@...il.com>
Date: Mon, 9 Feb 2009 21:22:03 +0200

> 2009/2/9 Krzysztof Halasa <khc@...waw.pl>:
> >
> > That means the consistent/coherent mapping isn't really
> > consistent/coherent (uncached), right? Perhaps there is some way to fix
> > this instead of changing the drivers to avoid the problematic area?
> >
> Yes.
> 
> The other way could be to add a config parameter that allows to
> explicitly set CONFIG_NOT_COHERENT_CACHE. I have not tried this,
> probably because the necessary code wasn't in arch/powerpc until
> 2.6.21.
> 
> Anyway, now I have tested with 2.6.24, and the problem still exists.

Ok.

The issue are descriptors that are _written_ by both the cpu
and the device.  That is the problematic case here.

e100 had a similar problem and changes were made there too to
accomodate such system types.

If only the cpu or only the device writes to the descriptor
(which is the most common design these days) there are no
problems.

So as promised I'll have to relook at this patch :-)
--
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