Bug 9189
Summary: | Oops in kernel 2.6.21-rc4 through 2.6.23, page allocation failure | ||
---|---|---|---|
Product: | Networking | Reporter: | darko.koruga |
Component: | IPV4 | Assignee: | Herbert Xu (herbert) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
darko.koruga
2007-10-19 01:35:28 UTC
On Sat, Oct 20, 2007 at 12:00:15AM +0800, Herbert Xu wrote: > >> > >> Backtrace #1: > >> page allocation failure. order:1, mode:0x20 > >> [<c0131581>] __alloc_pages+0x2e1/0x300 > >> [<c0144bee>] cache_alloc_refill+0x29e/0x4b0 > >> [<c0144e6e>] __kmalloc+0x6e/0x80 > >> [<c0227103>] __alloc_skb+0x53/0x110 > >> [<c024de5c>] tcp_collapse+0x1ac/0x370 > >> [<c024e11d>] tcp_prune_queue+0xfd/0x2c0 > >> [<c024eaad>] tcp_data_queue+0x7cd/0xbb0 > >> [<c0225c2d>] skb_checksum+0x4d/0x2a0 > >> [<c02504ee>] tcp_rcv_established+0x36e/0x6a0 > >> [<c02561e4>] tcp_v4_do_rcv+0xb4/0x2a0 > >> [<c0131379>] __alloc_pages+0xd9/0x300 > >> [<c0258269>] tcp_v4_rcv+0x6a9/0x6c0 > >> [<c023ddb1>] ip_local_deliver+0x91/0x110 > >> [<c023e130>] ip_rcv+0x230/0x3c0 > >> [<c0227103>] __alloc_skb+0x53/0x110 > >> [<c022b742>] netif_receive_skb+0x152/0x1e0 > >> [<c022ce6f>] process_backlog+0x6f/0xe0 > >> [<c022cf3c>] net_rx_action+0x5c/0xf0 > >> [<c0115af2>] __do_softirq+0x42/0x90 > >> [<c0115b67>] do_softirq+0x27/0x30 > >> [<c01044fd>] do_IRQ+0x3d/0x70 > >> [<c0115818>] sys_gettimeofday+0x28/0x80 > >> [<c0102967>] common_interrupt+0x23/0x28 > >> ======================= I knew this looked familiar. In fact I'd already sent a patch to fix this back in June 2006 but it seems to have been lost. Here it is again rediffed against today's kernel: [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> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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)) From: Herbert Xu <herbert@gondor.apana.org.au> Date: Sun, 21 Oct 2007 12:56:01 +0800 > [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> Applied, I'll push this to -stable too, thanks! I have finally found time to test this fix. I used stock 2.6.23 kernel (Fix tcp_mem[] initialization commit included) with manually applied Herbert's patch. I issued make clean && make, installed new kernel and rebooted. Unfortunately I still get an oops with this patch: opera: page allocation failure. order:1, mode:0x4020 [<c013d442>] __alloc_pages+0x2e2/0x300 [<c01529a7>] __slab_alloc+0x177/0x400 [<c02bd3fb>] ip_local_deliver+0x9b/0x180 [<e0825e07>] rhine_interrupt+0x637/0xae0 [via_rhine] [<c015382f>] __kmalloc_track_caller+0x7f/0xb0 [<e0825e07>] rhine_interrupt+0x637/0xae0 [via_rhine] [<c02a2737>] __alloc_skb+0x57/0x120 [<e0825e07>] rhine_interrupt+0x637/0xae0 [via_rhine] [<c01368e5>] handle_IRQ_event+0x25/0x50 [<c0137df2>] handle_level_irq+0x42/0xa0 [<c0105c32>] do_IRQ+0x42/0x80 [<c011b4a8>] sys_gettimeofday+0x28/0x80 [<c01040cf>] common_interrupt+0x23/0x28 ======================= Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 186, btch: 31 usd: 8 Cold: hi: 62, btch: 15 usd: 54 Active:91695 inactive:30613 dirty:6895 writeback:45 unstable:0 free:764 slab:3146 mapped:13299 pagetables:455 bounce:0 DMA free:2004kB min:88kB low:108kB high:132kB active:8984kB inactive:1872kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 492 492 Normal free:1052kB min:2792kB low:3488kB high:4188kB active:357796kB inactive:120580kB present:503876kB pages_scanned:111 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 7*4kB 1*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2004kB Normal: 9*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1052kB Swap cache: add 18662, delete 17011, find 19/27, race 0+0 Free swap = 825272kB Total swap = 899600kB Free swap: 825272kB 131056 pages of RAM 0 pages of HIGHMEM 2006 reserved pages 63871 pages shared 1651 pages swap cached 6895 pages dirty 45 pages writeback 13299 pages mapped 3146 pages slab 455 pages pagetables eth0: Inconsistent Rx descriptor chain. Should I open a new bug report with the above stacktrace ? On Tue, Nov 06, 2007 at 08:43:18AM -0800, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9189 > > > > > > ------- Comment #4 from darko.koruga@siol.net 2007-11-06 08:43 ------- > Should I open a new bug report with the above stacktrace ? Yes please do. This looks like a bug in the VIA-Rhine driver. Are you using jumbo frames? That's the only way this can happen. Cheers, Thanks, I will create a new bug report. And to answer your question: no, this is a 100Mbit card, ifconfig says MTU:1500 |