Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750935AbWEREg2 (ORCPT ); Thu, 18 May 2006 00:36:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750968AbWEREg2 (ORCPT ); Thu, 18 May 2006 00:36:28 -0400 Received: from omx2-ext.sgi.com ([192.48.171.19]:17586 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1750935AbWEREgO (ORCPT ); Thu, 18 May 2006 00:36:14 -0400 From: Paul Jackson To: Andrew Morton Cc: David Chinner , Simon.Derr@bull.net, linux-kernel@vger.kernel.org, Nick Piggin , Christoph Lameter , Paul Jackson Date: Wed, 17 May 2006 21:36:07 -0700 Message-Id: <20060518043607.15898.97283.sendpatchset@jackhammer.engr.sgi.com> In-Reply-To: <20060518043556.15898.73616.sendpatchset@jackhammer.engr.sgi.com> References: <20060518043556.15898.73616.sendpatchset@jackhammer.engr.sgi.com> Subject: [PATCH 03/03] Cpuset: might_sleep_if check in cpuset_zones_allowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 38 From: Paul Jackson It's too easy to incorrectly call cpuset_zone_allowed() in an atomic context without __GFP_HARDWALL set, and when done, it is not noticed until a tight memory situation forces allocations to be tried outside the current cpuset. Add a 'might_sleep_if()' check, to catch this earlier on, instead of waiting for a similar check in the mutex_lock() code, which is only rarely invoked. Signed-off-by: Paul Jackson --- kernel/cpuset.c | 1 + 1 file changed, 1 insertion(+) --- 2.6.17-rc4-mm1.orig/kernel/cpuset.c 2006-05-17 20:31:22.577065566 -0700 +++ 2.6.17-rc4-mm1/kernel/cpuset.c 2006-05-17 20:31:36.261218192 -0700 @@ -2261,6 +2261,7 @@ int __cpuset_zone_allowed(struct zone *z if (in_interrupt()) return 1; node = z->zone_pgdat->node_id; + might_sleep_if(!(gfp_mask & __GFP_HARDWALL)); if (node_isset(node, current->mems_allowed)) return 1; if (gfp_mask & __GFP_HARDWALL) /* If hardwall request, stop here */ -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 - 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/