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: <20100519130710.GX2516@laptop>
Date:	Wed, 19 May 2010 23:07:10 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	David Woodhouse <dwmw2@...radead.org>
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, May 19, 2010 at 01:48:45PM +0100, David Woodhouse wrote:
> On Wed, 2010-05-12 at 13:03 +1000, Nick Piggin wrote:
> > I don't think it's necessarily a good idea. MINALIGN is an enforced
> > minimum alignment and the allocator has no leeway in reducing this.
> > In a UP system, or in a memory constrained system, it might be a better
> > idea to pack objects more tightly, for example.
> > 
> > If we allow drivers to assume kmalloc is cacheline aligned, it will be
> > (practically) impossible to revert this because it would require driver
> > audits.
> 
> No, we definitely don't, and shouldn't, allow drivers to assume that
> kmalloc is cacheline-aligned.

Good.


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

Either way, yes the arch should take care of those details.

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

> 
> But it looks like ARM, PowerPC, SH, MIPS, Microblaze, AVR32 and all
> unconditionally cache-coherent architectures _do_ get it right already.
> 
> > I think adding to the DMA API would be a better idea. If the arch knows
> > that kmalloc is suitable for the job directly, it can be used. Drivers
> > can use the new interface, and kmalloc doesn't get saddled with
> > alignment requirements.
> 
> No, that would be a change which would require auditing all drivers. The
> _current_ rule is that buffers returned from kmalloc() are OK for DMA.
> 
> -- 
> 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/