linux-kernel - Re: [patch 2/4] mempolicy: support optional mode flags

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: <alpine.DEB.1.00.0802111345170.3908@chino.kir.corp.google.com>
Date:	Mon, 11 Feb 2008 13:52:53 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Jackson <pj@....com>
cc:	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	akpm@...ux-foundation.org, clameter@....com, ak@...e.de,
	mel@....ul.ie, linux-kernel@...r.kernel.org
Subject: Re: [patch 2/4] mempolicy: support optional mode flags

On Mon, 11 Feb 2008, Paul Jackson wrote:

> If things go as I hope, I expect to spend a couple of days this week
> reviving my earlier patch RFC that a couple of you on this cc list saw,
> concerning how nodes are numbered in mempolicy nodemasks.  Certainly
> the work being done in these various recent patches will affect my
> patch ... it's in the same code.
> 

With my patchset I don't believe there is any ambiguity in how nodes are 
numbered anymore.

The node remap is suppressed on policy rebind if MPOL_F_STATIC_NODES is 
passed by the user either on mbind() or set_mempolicy()[*].  So in that 
case, the user is always referring to absolte physical node numbers; 
without the flag, the user is referring to relative node numbers since it 
can be remapped when the mempolicy context changes.

 [*] Or with tmpfs by appending '=static' to the policy mode at mount
     time.

> David or Lee -- could you recommend to me which of these various patches
> of late I should apply first in my workarea, in what order, before I
> add my patch?

That's a good question; when I prepared this patchset I simply based it 
off Linus' latest git + V3 of Lee's contextualize_policy() patch that was 
posted to LKML on February 8:

	http://marc.info/?l=linux-kernel&m=120250000001182

Lee has talked about another patchset that he hasn't posted (at least not 
lately) based on Mel's two zonelist work.  I'm not sure of that status of 
that right now and since Lee is idle this week I would recommend applying 
V3 of his patch plus my five (there was a fifth patch posted in response 
to KOSAKI Motohiro's findings of a mpol_new() memory leak:

	http://marc.info/?l=linux-kernel&m=120276002725325

> After fixing up conflicts between my earlier patch and
> these good patches of yours, I'll try to do some testing of the code
> paths that my patch most likely affected, to ensure that I don't break
> any existing code.  I'll also probably have some more detailed review
> comments on these patches, as I work through them and resolve conflicts
> between them and my patch.
> 

Sounds good.

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