From patchwork Thu Mar 31 00:52:02 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 88996 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 89D5FB6FCD for ; Thu, 31 Mar 2011 11:53:08 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756700Ab1CaAwm (ORCPT ); Wed, 30 Mar 2011 20:52:42 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:55255 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756556Ab1CaAwl (ORCPT ); Wed, 30 Mar 2011 20:52:41 -0400 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 0DEFA24C088; Wed, 30 Mar 2011 17:52:03 -0700 (PDT) Date: Wed, 30 Mar 2011 17:52:02 -0700 (PDT) Message-Id: <20110330.175202.235689626.davem@davemloft.net> To: davej@redhat.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: loading sctp fails an order 10 allocation. From: David Miller In-Reply-To: <20110330234020.GA24517@redhat.com> References: <20110330234020.GA24517@redhat.com> X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Dave Jones Date: Wed, 30 Mar 2011 19:40:21 -0400 > modprobe sctp on my laptop does this which looks crazy.. ... > it doesn't look like the hashtable allocation code has changed in ages, so I'm > not sure why I've never triggered this before. I decided to take a break from watching Charlie Sheen dubstep remixes in a loop on youtube to look at this bug. This situation is amusing because SCTP actually tries to allocate an initially smaller hash table than, for example, the DCCP module does. But DCCP won't show the behavior you see. The thing that's different is that SCTP forgets to pass __GFP_NOWARN to the allocation. The code there is able to handle failures just fine and simply tries to progressively grab a smaller table when that happens. I'll commit the following to net-2.6, thanks. Now back to Adonis dubsteps... -------------------- sctp: Pass __GFP_NOWARN to hash table allocation attempts. Like DCCP and other similar pieces of code, there are mechanisms here to try allocating smaller hash tables if the allocation fails. So pass in __GFP_NOWARN like the others do instead of emitting a scary message. Reported-by: Dave Jones Signed-off-by: David S. Miller --- net/sctp/protocol.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index 152976e..d5bf91d 100644 --- a/net/sctp/protocol.c +++ b/net/sctp/protocol.c @@ -1205,7 +1205,7 @@ SCTP_STATIC __init int sctp_init(void) if ((sctp_assoc_hashsize > (64 * 1024)) && order > 0) continue; sctp_assoc_hashtable = (struct sctp_hashbucket *) - __get_free_pages(GFP_ATOMIC, order); + __get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order); } while (!sctp_assoc_hashtable && --order > 0); if (!sctp_assoc_hashtable) { pr_err("Failed association hash alloc\n"); @@ -1238,7 +1238,7 @@ SCTP_STATIC __init int sctp_init(void) if ((sctp_port_hashsize > (64 * 1024)) && order > 0) continue; sctp_port_hashtable = (struct sctp_bind_hashbucket *) - __get_free_pages(GFP_ATOMIC, order); + __get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order); } while (!sctp_port_hashtable && --order > 0); if (!sctp_port_hashtable) { pr_err("Failed bind hash alloc\n");