From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH 2.6.24-mm1] Mempolicy: silently restrict nodemask to allowed nodes V3 From: Lee Schermerhorn In-Reply-To: References: <1202748459.5014.50.camel@localhost> <20080212091910.29A0.KOSAKI.MOTOHIRO@jp.fujitsu.com> <1202828903.4974.8.camel@localhost> <1202861240.4974.25.camel@localhost> <1202920363.4978.69.camel@localhost> Content-Type: text/plain Date: Wed, 13 Feb 2008 11:56:18 -0700 Message-Id: <1202928979.4978.80.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: David Rientjes Cc: KOSAKI Motohiro , Andrew Morton , linux-mm List-ID: On Wed, 2008-02-13 at 10:32 -0800, David Rientjes wrote: > On Wed, 13 Feb 2008, Lee Schermerhorn wrote: > > > I'm not sure why you don't want to require the nodemask to be NULL/empty > > in the case of MPOL_DEFAULT. Perhaps it's from a code complexity > > viewpoint. Or maybe you think we're being kind to the programmer by > > cutting them some slack. Vis a vis the latter, I would argue that we're > > not doing a programmer any favor by letting this slide by. MPOL_DEFAULT > > takes no nodemask. So, if a non-empty nodemask is passed, the > > programmer has done something wrong. > > > > I mentioned on LKML that I've currently folded all the current logic of > mpol_check_policy() as it stands this minute in Linus' tree into > mpol_new() so that non-empty nodemasks are no longer accepted for > MPOL_DEFAULT. > Right. That's why I mentioned "beating a dead horse". I was answering mail this morning in the order I read them. This seemed to me to warrant a response, independent of the lkml stream. Again, just to get on the same page. Honest. Not just to be a ... :-) Thanks, Lee -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org