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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 May 2010 13:31:48 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	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>,
	Johannes Weiner <jw@...ix.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	Matt Mackall <mpm@...enic.com>
Subject: Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines

On Tue, May 11, 2010 at 12:52, Dmitry Torokhov wrote:
> On Tue, May 11, 2010 at 09:42:03AM +0300, Pekka Enberg wrote:
>> On Tue, May 11, 2010 at 9:33 AM, Dmitry Torokhov wrote:
>> >> what guarantee exactly do you have for that statement ?
>> >
>> > The data is kmalloced, kmalloc aligns on cacheline boundary AFAIK which
>> > means that next kmalloc data chunk will not share "our" cacheline.
>>
>> No, there are no such guarantees. kmalloc() aligns on
>> ARCH_KMALLOC_MINALIGN or ARCH_SLAB_MINALIGN depending on which is
>> bigger but beyond that, there are no guarantees. You can, of course,
>> use kmem_cache_create() with SLAB_HWCACHE_ALIGN to align on cacheline
>> boundary.
>
> The architectures that we are trying to deal with here should be forcing
> kmalloc to the cache boundary already though - otherwise they would not
> be able to used kmalloced memory for DMA buffers at all. Or am I utterly
> lost here?

i dont want to restrict the driver so that it implicitly only works on
certain arches.  that kind of goes against the entire point of the
driver model.  the only thing this driver needs is a SPI bus, and
people can easily do that on most every arch.
-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/