linux-kernel - Re: ZONE

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]

Message-ID: <4511E1CA.6090403@mbligh.org>
Date:	Wed, 20 Sep 2006 17:50:18 -0700
From:	"Martin J. Bligh" <mbligh@...igh.org>
To:	Andrew Morton <akpm@...l.org>
Cc:	linux-kernel@...r.kernel.org,
	Christoph Lameter <clameter@...r.sgi.com>
Subject: Re: ZONE_DMA

Andrew Morton wrote:
> (Subject rewritten, developer cc'ed, thwap delivered)
> 
> On Wed, 20 Sep 2006 17:09:57 -0700
> "Martin J. Bligh" <mbligh@...igh.org> wrote:
> 
>>> introduce-config_zone_dma.patch
>>> optional-zone_dma-in-the-vm.patch
>>> optional-zone_dma-in-the-vm-tidy.patch
>>> optional-zone_dma-for-i386.patch
>>> optional-zone_dma-for-x86_64.patch
>>> optional-zone_dma-for-ia64.patch
>>> remove-zone_dma-remains-from-parisc.patch
>>> remove-zone_dma-remains-from-sh-sh64.patch
>> Would it not make sense to define what ZONE_DMA actually means
>> consistently before trying to change it? The current mess across
>> different architectures seems like a disaster area to me.
>>
>> What DOES requesting ZONE_DMA from a driver actually mean?
>>
> 
> AFAIK it means "floppy disks" ;)

That's the problem - it doesn't mean that at all, except on ia32.
It means totally different things on different architectures. IIRC,
on PPC64, it's all of memory.

Having something that's used in generic code that means random
things on different arches just seems like a recipe for disaster
to me.

> My concern about these patches is that they'll only be useful for
> self-compiled kernels, because distros will be forced to enable ZONE_DMA
> for evermore anyway.
> 
> If that's correct then perhaps we should drop these patches, because they
> will serve to weaken ongoing testing.

Well, I think we actually need to define what it means before we
mess with it any more. It's not Christoph's fault that it's broken.
But messing with something that's pretty much undefined will likely
have undefined consequences.

Christoph Lameter wrote:
 > Actually the desaster is cleaned up by this patch. A couple of
 > architectures that were wrongly using ZONE_DMA now use ZONE_NORMAL.

OK ... but requesting ZONE_DMA means what? DMAable for which device?
Is it always a floppy disk? on some platforms a PCI card? And how
is the VM meant to know what the device is capable of anyway?

Having an arch-specific definition of the limit is arbitrary and
useless, is it not? The limit is imposed by the device and its
driver, we're not communicating it into any sensible way into the
VM code, AFAICS. Unless we're pretending we never call it from
generic code, which seems woefully unlikely to me.

Are we redefining ZONE_DMA to always be 16MB limit across all
architectures? At least that'd be consistent.

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