netdev - Re: [PATCH 1/2] pcnet32: only allocate init

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, 7 Mar 2007 12:15:26 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"Ralf Baechle" <ralf@...ux-mips.org>
Cc:	"Don Fry" <pcnet32@...izon.net>, jgarzik@...ox.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] pcnet32: only allocate init_block dma consistent

On 3/7/07, Ralf Baechle <ralf@...ux-mips.org> wrote:
> GFP_* flags have no influence on caching or prefetching.

The zone modifier flags (like GFP_DMA) can in principle affect the
cache/prefetch policy, since they affect what physical address range
the memory is allocated from.  I don't know whether Linux uses this
effect intentionally, but I would not be the least bit surprised if
virtual machines commonly treat the traditional 16MB of low physical
memory differently from the rest of the address space.

Looking at the i386 implementation of dma_alloc_coherent (underlying
pci_alloc_consistent), it's not clear to me how this interferes with
cacheability of the allocated block.  Maybe it doesn't.  The alpha
version of pci_alloc_consistent, on the other hand, does interesting
things to make the memory visible to PCI.  Don, what arches did you
have in mind when you commented on caching issues?

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html