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.0802111135090.1671@chino.kir.corp.google.com>
Date:	Mon, 11 Feb 2008 11:40:48 -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/4] mempolicy: convert MPOL constants to enum

On Mon, 11 Feb 2008, Christoph Lameter wrote:

> > The policy member of struct mempolicy is also converted from type short
> > to type unsigned short.  A negative policy does not have any legitimate
> > meaning, so it is possible to change its type in preparation for adding
> > optional mode flags later.
> 
> The second paragraphs seems to indicate that such an approach does not 
> work since we also use MPOL_xx constants to set flags in the memory 
> policies?
> 

Not sure I'm understanding your question, sorry.

Mempolicy modes have always been int constants because it doesn't make 
sense to combine them.  Putting them into 'enum mempolicy_mode' leaves 
that unchanged.

Mempolicy flags can be combined (even though my patchset only currently 
implements one, it's easy to implement others).  So they definitely cannot 
be enum constants.

Regardless, storing the policy (mode | flags) in struct mempolicy as a 
'short' doesn't help since a negative policy doesn't mean anything.  In 
preparation for allowing the upper MPOL_FLAG_SHIFT bits to be used to 
store the flags of this member, I converted it to 'unsigned short'.  This 
is because the API with userspace is through 'int', which is implicitly 
signed, and we don't want to sign-extend the upper bit if it's ever used 
to hold a mempolicy flag.

		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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ