linux-kernel - Re: [PATCH 6/6] atmel

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: <20080123143503.764bc8cf@dhcp-252-066.norway.atmel.com>
Date:	Wed, 23 Jan 2008 14:35:03 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	Marc Pignat <marc.pignat@...s.ch>
Cc:	Andrew Victor <linux@...im.org.za>, kernel@...32linux.org,
	linux-kernel@...r.kernel.org, Remy Bohmer <linux@...mer.net>,
	Chip Coldwell <coldwell@...hat.com>
Subject: Re: [PATCH 6/6] atmel_serial: Add DMA support

On Wed, 23 Jan 2008 14:18:38 +0100
Marc Pignat <marc.pignat@...s.ch> wrote:

> On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
> > Ok, but then any power of two larger than the cache line size should be
> > fine, assuming kmalloc() returns a properly aligned buffer.
> Yes. The memory should be allocated using GFP_KERNEL | GFP_DMA flags, but this
> is probably a nop on at91 and avr32.

GFP_DMA doesn't have anything to do with alignment, AFAIK.

> I prepare a patch using the generic dma api (allocation + dma mapping in one
> call = simpler code).

No, please don't. If you're thinking of dma_alloc_coherent(), it means
that the cache will be bypassed when accessing the buffer (slower), and
that the size will be rounded up to the next multiple of the page size
(larger). If the sole purpose of doing that is to get properly aligned
buffers, we might as well use the page allocator directly.

kmalloc() does return cache-aligned buffers on AVR32, so a patch like
that would have only downsides. I'm not sure about ARM though.

> > Other than that, I can't see any reason why a platform with 64 byte
> > cache lines should need larger buffers than one with 32 byte cache
> > lines.
> If the memory at the end of the cacheline is used by the cpu, it will be
> corrupted while you call dma_sync_single_for_cpu(..., DMA_FROM_DEVICE);

True, but if that happens, the right fix is to provide a suitable
definition of ARCH_KMALLOC_MINALIGN on ARM.

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