From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Jones Subject: ppp/l2tp doing oversized allocations ? Date: Mon, 14 May 2012 12:29:23 -0400 Message-ID: <20120514162923.GA4439@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Fedora Kernel Team To: netdev@vger.kernel.org Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45320 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757183Ab2ENQ32 (ORCPT ); Mon, 14 May 2012 12:29:28 -0400 Content-Disposition: inline Sender: netdev-owner@vger.kernel.org List-ID: We just got this trace from reported by a Fedora user running 3.3.4 :WARNING: at mm/page_alloc.c:2204 __alloc_pages_nodemask+0x231/0x8f0() :Call Trace: : [] warn_slowpath_common+0x7f/0xc0 : [] warn_slowpath_null+0x1a/0x20 : [] __alloc_pages_nodemask+0x231/0x8f0 : [] ? dev_queue_xmit+0x1db/0x640 : [] ? ip_forward_options+0x1f0/0x1f0 : [] ? neigh_direct_output+0x11/0x20 : [] ? ip_finish_output+0x17e/0x2f0 : [] ? ip_forward_options+0x1f0/0x1f0 : [] alloc_pages_current+0xa3/0x110 : [] __get_free_pages+0x14/0x50 : [] kmalloc_order_trace+0x3f/0xd0 : [] ? xfrm4_output_finish+0x27/0x40 : [] __kmalloc+0x177/0x1a0 : [] ? ip_queue_xmit+0x156/0x400 : [] pskb_expand_head+0x87/0x310 : [] ? __mod_zone_page_state+0x49/0x50 : [] pppol2tp_xmit+0x1ed/0x220 [l2tp_ppp] : [] ppp_push+0x15b/0x650 [ppp_generic] : [] ? pskb_expand_head+0x244/0x310 : [] ? free_compound_page+0x1b/0x20 : [] ? __put_compound_page+0x23/0x30 : [] ? put_compound_page+0x125/0x1c0 : [] ppp_xmit_process+0x46f/0x660 [ppp_generic] : [] ppp_start_xmit+0x138/0x1d0 [ppp_generic] : [] dev_hard_start_xmit+0x332/0x6d0 : [] sch_direct_xmit+0xfa/0x1d0 : [] __qdisc_run+0xa6/0x130 : [] dev_queue_xmit+0x1be/0x640 : [] ? ip_forward_options+0x1f0/0x1f0 : [] neigh_direct_output+0x11/0x20 : [] ip_finish_output+0x17e/0x2f0 : [] ip_output+0x66/0xa0 : [] ? __ip_local_out+0xa2/0xb0 : [] xfrm_output_resume+0x38e/0x3f0 : [] ? kfree+0x3b/0x150 : [] ? cryptd_free+0x60/0x60 : [] esp_output_done+0x30/0x40 [esp4] : [] authenc_request_complete+0x14/0x20 [authenc] : [] crypto_authenc_givencrypt_done+0x2e/0x40 [authenc] : [] cryptd_blkcipher_crypt+0x5c/0x70 : [] cryptd_blkcipher_encrypt+0x1c/0x20 : [] cryptd_queue_worker+0x56/0x80 : [] process_one_work+0x11e/0x470 : [] worker_thread+0x15f/0x360 : [] ? manage_workers+0x230/0x230 : [] kthread+0x93/0xa0 : [] kernel_thread_helper+0x4/0x10 : [] ? kthread_freezable_should_stop+0x70/0x70 : [] ? gs_change+0x13/0x13 That WARN statement is this in the page allocator.. 2197 /* 2198 * In the slowpath, we sanity check order to avoid ever trying to 2199 * reclaim >= MAX_ORDER areas which will never succeed. Callers may 2200 * be using allocators in order of preference for an area that is 2201 * too large. 2202 */ 2203 if (order >= MAX_ORDER) { 2204 WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); 2205 return NULL; 2206 } Dave