linux-kernel - Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

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: <20070813235518.GK3406@bingen.suse.de>
Date:	Tue, 14 Aug 2007 01:55:18 +0200
From:	Andi Kleen <ak@...e.de>
To:	Christoph Lameter <clameter@....com>
Cc:	Andi Kleen <ak@...e.de>, Mel Gorman <mel@...net.ie>,
	Lee.Schermerhorn@...com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

On Mon, Aug 13, 2007 at 03:52:54PM -0700, Christoph Lameter wrote:
> On Tue, 14 Aug 2007, Andi Kleen wrote:
> 
> > > I am not sure what you mean by that. Ia64 ZONE_DMA == x86_84 ZONE_DMA32?
> > 
> > Hmm, when I wrote GFP_DMA32 it was a #define GFP_DMA32 GFP_DMA 
> > on ia64 so that drivers not need to ifdef.  Someone nasty
> > seems to have removed that too. I guess it would be best
> > to readd.
> 
> What would be the point?

"so that drivers not need to ifdef" 

> > But then it wouldn't make sense to have GFP_DMA on ia64 and GFP_DMA32
> > on x86. Since driver writers are more likely to test on x86
> > I would recommend ia64 having compatible semantics. It'll
> > save everybody trouble long term. This means it wouldn't 
> > help on IA64 machines that don't have a DMA zone -- they
> > would still need to validate drivers especially -- but at least
> > the others.
> 
> There are no compatible semantics. ZONE_DMA may mean something different 

Yes current GFP_DMA is a mess.

But GFP_DMA32 is relatively clean and it means that same
as GFP_DMA on IA64. So ia64 could relatively painless switch
to it.

Anyways, I must admit ia64 is not my main concern. If you or Tony
don't like GFP_DMA32 then keep using GFP_DMA if you want, but just don't
complain about driver porting problems. I'm just trying to make
your lives easier (that is why i did the #define originally),
not be annoying.

> for each arch depending on its need. An arch may not have a need for a 4GB 
> boundary (such as s390).

I don't worry about s390 too much because the s390 driver universe
doesn't really overlap with the x86 driver universe. So whatever
semantics they have it's their own issue.

If they ever build s390s with PCI slots that can take arbitary card 
they might have an issue, but I won't worry about this.

-Andi

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