linux-kernel - Re: [patch 1/4] mempolicy: convert MPOL constants to enum

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.0802121911040.3418@chino.kir.corp.google.com>
Date:	Tue, 12 Feb 2008 19:17:02 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Paul Jackson <pj@....com>
cc:	clameter@....com, Lee.Schermerhorn@...com,
	akpm@...ux-foundation.org, ak@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/4] mempolicy: convert MPOL constants to enum

On Tue, 12 Feb 2008, Paul Jackson wrote:

> ==> If each time I look at some 'flags' field, I have to think of it
> as a couple of things glued together that I will have to pick apart to
> use, that's more mental work than seeing those two things explicit and
> separate, through most of the mempolicy.c code <==
> 

That doesn't logically follow because the aggregate of the mode and the 
optional flags _are_ the policy itself.  If you want to know whether a 
policy is interleave, for example, and don't care whether it is referring 
to static (absolute) node ids, then you need to mask that off.

The reality of the kernel code is that these policies are not only 
restricted to kernel/mempolicy.c.  They are also shared with filesystem 
code that store them in a single member of a struct as well.  The 
interface between those two are functions that would now need to be 
modified to include additional parameters to pass the flags along.

Additionally, these flags need to be "glued together" with the mode in 
userspace to pass to the syscalls anyway, so they're facing the exact 
same challenge.  So once this gets a little traction, I think it will 
quickly become the norm for how you think about the 'policy' member of the 
struct.

		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/