linux-kernel - Re: [LKML] Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines

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: <1274275067.6930.10073.camel@macbook.infradead.org>
Date:	Wed, 19 May 2010 14:17:47 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Marc Gauthier <marc@...silica.com>,
	Mike Frysinger <vapier.adi@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Johannes Weiner <jw@...ix.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oskar Schirmer <os@...ix.com>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Glöckner <dg@...ix.com>,
	Oliver Schneidewind <osw@...ix.com>,
	David Rientjes <rientjes@...gle.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Chris Zankel <chris@...kel.net>,
	Piet Delaney <Piet.Delaney@...silica.com>
Subject: Re: [LKML] Re: [PATCH v3] ad7877: keep dma rx buffers in seperate
 cache lines

On Wed, 2010-05-19 at 23:07 +1000, Nick Piggin wrote:
> On Wed, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote:
> > However, we _do_ allow drivers to assume that kmalloc is DMA-safe. That
> > happens to mean "cacheline-aligned" for cache-incoherent architectures,
> > but drivers should never really have to think about that.
> 
> DMA-safe for GFP_DMA, or all kmalloc?

Try not to think about that. Seriously, look over there! A kitten!

(You have to use the DMA API anyway, so swiotlb will handle things if
you're trying to use pages which are above the range that certain
devices can reach. But we're only talking about the problems of sharing
cache lines here; don't worry about that bit.)

> > > So whenever strengthening API guarantees like this, it is better to be
> > > very careful and conservative. Probably even introducing a new API with
> > > the stronger semantics (even if it is just a wrapper in the case where
> > > KMALLOC_MINALIGNED *is* cacheline sized).
> > 
> > We're not talking about strengthening API guarantees. It's _always_ been
> > this way; it's just that some architectures are buggy.
> 
> It just appeared, in the post I replied to, that there was a suggestion
> of making it explicitly cacheline aligned. If I misread that, ignore
> me.

Actually I think you read it just fine -- but it was misguided. They
meant to say "cacheline aligned on architectures with cache-incoherent
DMA which need that". But that's what ARCH_KMALLOC_MINALIGN is _already_
supposed to do. If any architecture needs to set ARCH_KMALLOC_MINALIGN
but doesn't, that's broken.

The 'cacheline aligned' misconception did manage to get into the ad7877
driver in commit 3843384a though -- it now uses ____cacheline_aligned
instead of __attribute__((__aligned__(ARCH_KMALLOC_MINALIGN))) as it
should.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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