| 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
| ||
|
Message-Id: <20090210.152143.176850113.davem@davemloft.net> Date: Tue, 10 Feb 2009 15:21:43 -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>: > > Potentially any driver is affected by such coherency problem, this can't > > be specific to 21040. > > > I agree. That talks for the config solution. I think the pci_alloc_consistent() implementation for your particular platform should be fixed instead :-) It should be using uncacheable cpu mappings of the returned memory if the cpu lacks cache coherency with DMA. Peppering all kinds of drivers with this kind of change being proposed here is not the way to handle this problem. It makes the creation of the abstractions we created with pci_alloc_consistent() and friends totally useless. Drivers have to be able to say "what I write to this memory the device will see, and what the device writes the cpu will see" and they have to be able to say this regardless of details like cache alignment and other things that they should have no business knowing about. -- 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
Powered by blists - more mailing lists