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: <m3vdrja6oe.fsf@intrepid.localdomain>
Date:	Mon, 09 Feb 2009 17:58:25 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Risto Suominen <risto.suominen@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 002/002] de2104x: support for systems lacking cache  coherence

Risto Suominen <risto.suominen@...il.com> writes:

>> 1) {pci,dma}_alloc_{consistent,coherent}() give kernel mappings of
>>   the buffer with the cache disabled.
                ^^^^^^^^^^^^^^^^^^^^^^^

> Sounds good, but does not seem to help. My theory is that when the cpu
> is writing to one descriptor, it accidentally overwrites another
> descriptor, that has already been written to by the device, as there
> is only a single dirty bit, that makes the whole cacheline to be
> flushed.

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?

Potentially any driver is affected by such coherency problem, this can't
be specific to 21040.
-- 
Krzysztof Halasa
--
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