Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756772AbYGHOIf (ORCPT ); Tue, 8 Jul 2008 10:08:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753869AbYGHOIP (ORCPT ); Tue, 8 Jul 2008 10:08:15 -0400 Received: from g4t0014.houston.hp.com ([15.201.24.17]:11834 "EHLO g4t0014.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753628AbYGHOIN (ORCPT ); Tue, 8 Jul 2008 10:08:13 -0400 Subject: Re: [bug ?] do_get_mempolicy() From: Lee Schermerhorn Reply-To: lee.schermerhorn@hp.com To: David Rientjes Cc: John Blackwood , linux-kernel@vger.kernel.org, Joe Korty In-Reply-To: References: <486D3A4A.6000502@ccur.com> Content-Type: text/plain Organization: HP/OSLO Date: Tue, 08 Jul 2008 09:43:46 -0400 Message-Id: <1215524626.22680.13.camel@murky.zko.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2389 Lines: 68 On Thu, 2008-07-03 at 14:44 -0700, David Rientjes wrote: > On Thu, 3 Jul 2008, John Blackwood wrote: > > > Hi Lee, > > > > I'm having unexpected results with get_mempolicy(2) in 2.6.26, and > > I am hoping that you can either agree with me, or maybe comment on my > > misconceptions. > > > > When I have a task with no special task mempolicy (the default mempolicy), > > when I call get_mempolicy(2), it returns a policy value of 2 (MPOL_BIND) > > with a NULL nodemask. > > > > I believe that this is because of the code in do_get_mempolicy() that does: > > > > *policy |= pol->flags; > > > > in the else case when flags do not contain MPOL_F_NODE. > > > > I guess I don't understand why we are ORing in the pol->flags into the > > *policy value. For example, when this is for the default_policy, the > > MPOL_F_LOCAL flag (which has a value of 2) gets stuffed into the *policy > > location, and a get_mempolicy(2) caller sees this as the MPOL_BIND > > mempolicy. > > > > Maybe the "*policy |= pol->flags;" line should be removed ? > > > > You're right, the flags member of struct mempolicy has subsequently > changed to carry "internal" flags that are not supposed to be exposed to > userspace via the get_mempolicy() API. > > The following patch probably fixes it. > > Lee? David: Just getting back from long weekend. This looks good. I was thinking that, in addition to masking off the internal flags, we need to shift the flags into the upper half word. However, external flags are already shifted to the correct position, so just the mask is needed. > > Signed-off-by: David Rientjes Acked-by: Lee Schermerhorn > --- > mm/mempolicy.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -729,7 +729,7 @@ static long do_get_mempolicy(int *policy, nodemask_t *nmask, > } else { > *policy = pol == &default_policy ? MPOL_DEFAULT : > pol->mode; > - *policy |= pol->flags; > + *policy |= (pol->flags & MPOL_MODE_FLAGS); > } > > if (vma) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/