Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756709Ab1CaAwn (ORCPT ); Wed, 30 Mar 2011 20:52:43 -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 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 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2549 Lines: 69 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"); -- 1.7.4.2 -- 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/