linux-kernel - 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:	Tue, 11 May 2010 18:39:54 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	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-kernel@...r.kernel.org,
	Daniel Glöckner <dg@...ix.com>,
	Oliver Schneidewind <osw@...ix.com>,
	Nick Piggin <npiggin@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines

On Tue, May 11, 2010 at 17:53, Dmitry Torokhov wrote:
> On Tue, May 11, 2010 at 11:48:36PM +0200, Johannes Weiner wrote:
>> On Tue, May 11, 2010 at 04:54:41PM -0400, Mike Frysinger wrote:
>> > does the phrase "DMA safe buffer" imply cache alignment ?
>>
>> I guess that depends on the architectural requirements.  On x86,
>> apparently, not so much.  On ARM, probably yes, as it's the
>> requirement to properly maintain coherency.
>
> It looks liek ARM (and a few others) do this:
>
> [dtor@...mer work]$ grep -r ARCH_KMALLOC_MINALIGN arch/
> arch/sh/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
> arch/frv/include/asm/mem-layout.h:#define       ARCH_KMALLOC_MINALIGN           8
> arch/powerpc/include/asm/page_32.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
> arch/arm/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN      L1_CACHE_BYTES
> arch/microblaze/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN        L1_CACHE_BYTES
> arch/mips/include/asm/mach-tx49xx/kmalloc.h: * All happy, no need to define ARCH_KMALLOC_MINALIGN
> arch/mips/include/asm/mach-ip27/kmalloc.h: * All happy, no need to define ARCH_KMALLOC_MINALIGN
> arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALIGN 32
> arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALIGN 128
> arch/mips/include/asm/mach-generic/kmalloc.h:#define ARCH_KMALLOC_MINALIGN      128
> arch/avr32/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN    L1_CACHE_BYTES

if ARCH_KMALLOC_MINALIGN is not defined, the current allocators default to:
 slub - alignof(unsigned long long)
 slab - alignof(unsigned long long)
 slob - alignof(unsigned long)
which for many arches can mean an alignment of merely 4 or 8

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