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]

Date:	Wed, 12 May 2010 13:03:50 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Marc Gauthier <marc@...silica.com>
Cc:	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 Tue, May 11, 2010 at 07:07:35PM -0700, Marc Gauthier wrote:
> Mike Frysinger wrote:
> > lets look at the cacheline sizes for arches that dont set
> > ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES:
> >  - alplha - 32 or 64
> >  - frv - 32 or 64
> >  - blackfin - 32
> >  - parisc - 32 or 64
> >  - mn10300 - 16
> >  - s390 - 256
> >  - score - 16
> >  - sparc - 32
> >  - xtensa - 16 or 32
> >
> > assuming alpha and s390 handle cache coherency in hardware, it looks
> > to me like the proposed assumption (kmalloc returns cachealigned
> > pointers when cache management is in software) does not hold true.
> >
> > so should these other arches also be setting ARCH_KMALLOC_MINALIGN to
> > L1_CACHE_BYTES ?
> 
> IMHO, yes.  It just makes sense to avoid false-sharing issues, not to
> allocate unrelated blocks in the same cache line.
> 
> Also as it turns out (hope he doesn't me telling), Christian Zankel
> recently found a bug that was fixed exactly that way, by setting
> ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES for the Xtensa architecture.
> (Too recent to have percolated to mainline.)
> 
> A lot of the above might be cache line aligned (?).

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.

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

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.

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