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]

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