linux-kernel - Re: [patch 1/6] 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]

Date:	Wed, 27 Feb 2008 11:59:54 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Christoph Lameter <clameter@....com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Jackson <pj@....com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [patch 1/6] mempolicy: convert MPOL constants to enum

On Wed, 27 Feb 2008, Christoph Lameter wrote:

> On Mon, 25 Feb 2008, David Rientjes wrote:
> 
> >  struct mempolicy {
> >  	atomic_t refcnt;
> > -	short policy; 	/* See MPOL_* above */
> > +	unsigned short policy; 	/* See MPOL_* above */
> 
> The point here is to have a 16 bit value? There are no space savins due to 
> the alignment requirement of the union. Isnt it possible to use the enum 
> here? If not then what is the point of the enum?
> 

It was already a 16-bit value, that is unchanged, so no space savings is 
intended.

It is not possible to use the enum here because an additional unsigned 
short member to hold the mode flags is added to this struct later.  The 
increase in size of an int compared to an unsigned short would make the 
entire struct bigger; the alignment requirement of the union no longer 
prevents that.  After this patchset, it is 24 bytes in size while using 
unsigned short compared to 32 bytes while using int.

The enum is there to ensure MPOL_MAX is always accurate since it is now 
the sole way of testing for a proper mode being passed from the user, and
modes should be sequentially numbered.  A later change will add an array 
instance of a mempolicy_operations structure for the various modes.  It's 
just cleaner.

		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/