linux-kernel - Re: [patch 3/4] mempolicy: add MPOL_F_STATIC

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.0802131113190.9186@chino.kir.corp.google.com>
Date:	Wed, 13 Feb 2008 11:17:07 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
cc:	Paul Jackson <pj@....com>, akpm@...ux-foundation.org,
	clameter@....com, ak@...e.de, linux-kernel@...r.kernel.org,
	mel@....ul.ie
Subject: Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

On Wed, 13 Feb 2008, Lee Schermerhorn wrote:

> > Yeah, it gets tricky.  I'm not too sure about only pulling the mode and 
> > flags apart at mpol_new() time because perhaps, in the future, there will 
> > be flag and mode combinations that are only applicable for set_mempolicy() 
> > and not for mbind(), for example.  I can imagine that someday we may add a 
> > flag that applies only to a task mempolicy and not to a VMA mempolicy.
> 
> True.  Altho' at such a time, I'd probably argue for testing for and
> rejecting invalid mode/flag combinations in the respective
> functions :-).
> 

Yeah, and that would require the modes and flags to be split apart in 
sys_set_mempolicy() and sys_mbind() or at least in do_set_mempolicy() or 
do_mbind().  So if we see the possibility that we want to test for mode 
and flag combinations that perhaps differ between the set_mempolicy() and 
mbind() case, we have to do it in either of those two places.  I think we 
should do it there, as early as possible, like I did in my first patchset.

> OK.  I'm "caving"... :-)  Different views of consistency.  But,
> eventually, I hope we can replace the separate mode[, flags] and
> nodemask in the 'sb_info with a mempolicy and keep the details of modes,
> flags, etc. internal to mempolicy.c.
> 

I agree, I think keeping all of these implementation details inside 
mm/mempolicy.c is the best practice.  We'll still need to expose some of 
the details, such as the parsing of '=static' in the tmpfs mount option to 
add the MPOL_F_STATIC_NODES flag to the policy, but situations like that 
should be rare.

For extendability, I agree that the struct shmem_sb_info member should be 
a pointer to a mempolicy and not an int.

		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/