mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: nickpiggin@yahoo.com.au
Cc: frankvm@frankvm.com, linux-kernel@vger.kernel.org
Subject: Re: VM/networking crash cause #1: page allocation failure (order:1, GFP_ATOMIC)
Date: Thu, 08 Nov 2007 01:08:38 -0800 (PST)	[thread overview]
Message-ID: <20071108.010838.266803185.davem@davemloft.net> (raw)
In-Reply-To: <200711081655.38371.nickpiggin@yahoo.com.au>

From: Nick Piggin <nickpiggin@yahoo.com.au>
Date: Thu, 8 Nov 2007 16:55:38 +1100

> But it's an order-1 allocation, which may not be available due to
> fragmentation.

If the user is using an MTU of only 1500 (and thus not using
jumbo frames) he may be being bitten by a bug that was recently
fixed by Herbert Xu that made us use order > 0 pages accidently.

His fix is below:

commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Sun Oct 21 16:27:46 2007 -0700

    [NET]: Fix SKB_WITH_OVERHEAD calculation
    
    The calculation in SKB_WITH_OVERHEAD is incorrect in that it can cause
    an overflow across a page boundary which is what it's meant to prevent.
    In particular, the header length (X) should not be lumped together with
    skb_shared_info.  The latter needs to be aligned properly while the header
    has no choice but to sit in front of wherever the payload is.
    
    Therefore the correct calculation is to take away the aligned size of
    skb_shared_info, and then subtract the header length.  The resulting
    quantity L satisfies the following inequality:
    
    	SKB_DATA_ALIGN(L + X) + sizeof(struct skb_shared_info) <= PAGE_SIZE
    
    This is the quantity used by alloc_skb to do the actual allocation.
    
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f93f22b..369f60a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -41,8 +41,7 @@
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
 #define SKB_WITH_OVERHEAD(X)	\
-	(((X) - sizeof(struct skb_shared_info)) & \
-	 ~(SMP_CACHE_BYTES - 1))
+	((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
 #define SKB_MAX_ORDER(X, ORDER) \
 	SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
 #define SKB_MAX_HEAD(X)		(SKB_MAX_ORDER((X), 0))

  reply	other threads:[~2007-11-08  9:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05 17:42 Frank van Maarseveen
2007-11-06 22:01 ` Nick Piggin
2007-11-07 13:48   ` Frank van Maarseveen
2007-11-08  5:55     ` Nick Piggin
2007-11-08  9:08       ` David Miller [this message]
     [not found] <fa.lT2PJ6g8pT/00cmv4KeoEpWD3rU@ifi.uio.no>
2007-11-06 23:13 ` Robert Hancock
2007-11-07 13:56   ` Frank van Maarseveen
2007-11-07 15:22     ` Frank van Maarseveen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071108.010838.266803185.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=frankvm@frankvm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome