From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <47E9482B.7050005@cosmosbay.com> Date: Tue, 25 Mar 2008 19:44:59 +0100 From: Eric Dumazet MIME-Version: 1.0 Subject: Re: [Bugme-new] [Bug 10318] New: WARNING: at arch/x86/mm/highmem_32.c:43 kmap_atomic_prot+0x87/0x184() References: <20080325105750.ff913a83.akpm@linux-foundation.org> In-Reply-To: <20080325105750.ff913a83.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: netdev@vger.kernel.org, bugme-daemon@bugzilla.kernel.org, pstaszewski@artcom.pl, linux-mm@kvack.org, Christoph Lameter , Ingo Molnar List-ID: Andrew Morton a ecrit : > On Tue, 25 Mar 2008 02:50:54 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > > >> http://bugzilla.kernel.org/show_bug.cgi?id=10318 >> >> Summary: WARNING: at arch/x86/mm/highmem_32.c:43 >> kmap_atomic_prot+0x87/0x184() >> Product: Networking >> Version: 2.5 >> KernelVersion: 2.6.25-rc6-git7 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: IPV4 >> AssignedTo: shemminger@linux-foundation.org >> ReportedBy: pstaszewski@artcom.pl >> >> >> Latest working kernel version: 2.6.24 >> > > This is a post-2.6.24 regression. > > >> Software Environment: bgp/quagga >> > > The app does a lot of route management stuff. > > >> Problem Description: >> Pid: 0, comm: swapper Not tainted 2.6.25-rc6-git7 #1 >> [] warn_on_slowpath+0x40/0x4f >> [] fn_trie_lookup+0xe3/0x288 >> [] fib4_rule_action+0x3d/0x4d >> [] fib_rules_lookup+0x71/0xb6 >> [] fib_lookup+0x28/0x36 >> [] __rmqueue_smallest+0x83/0xe1 >> [] __rmqueue+0x13/0x172 >> [] kmap_atomic_prot+0x87/0x184 >> [] get_page_from_freelist+0x2c5/0x358 >> [] __alloc_pages+0x71/0x2cf >> [] __get_free_pages+0x39/0x47 >> [] neigh_create+0x2d8/0x40e >> [] _read_unlock_bh+0x5/0xd >> [] neigh_lookup+0x92/0x9b >> [] neigh_event_ns+0x3b/0x70 >> [] arp_process+0x1e5/0x534 >> [] dev_queue_xmit+0x279/0x29f >> [] ip_finish_output+0x1c6/0x1fc >> [] tc_classify+0x14/0x6b >> [] netif_receive_skb+0x29f/0x30e >> [] e1000_receive_skb+0x132/0x14c >> [] e1000_clean_rx_irq+0x1fa/0x29c >> [] e1000_clean+0x29f/0x427 >> [] net_rx_action+0x5c/0x14a >> [] __do_softirq+0x5d/0xc1 >> [] do_softirq+0x32/0x36 >> [] irq_exit+0x35/0x67 >> [] do_IRQ+0x73/0x82 >> [] common_interrupt+0x23/0x28 >> [] mwait_idle_with_hints+0x36/0x39 >> [] mwait_idle+0x0/0xa >> [] cpu_idle+0xa8/0xc8 >> ======================= >> ---[ end trace 6a93a9703f6a626e ]--- >> ------------[ cut here ]------------ >> > > This backtrace is a mess. > > >> WARNING: at arch/x86/mm/highmem_32.c:43 kmap_atomic_prot+0x87/0x184() >> Modules linked in: >> Pid: 0, comm: swapper Not tainted 2.6.25-rc6-git7 #1 >> [] warn_on_slowpath+0x40/0x4f >> [] fn_trie_lookup+0xe3/0x288 >> [] fib4_rule_action+0x3d/0x4d >> [] fib_rules_lookup+0x71/0xb6 >> [] fib_lookup+0x28/0x36 >> [] __rmqueue_smallest+0x83/0xe1 >> [] __rmqueue+0x13/0x172 >> [] kmap_atomic_prot+0x87/0x184 >> [] get_page_from_freelist+0x2c5/0x358 >> [] __alloc_pages+0x71/0x2cf >> [] __get_free_pages+0x39/0x47 >> [] neigh_create+0x2d8/0x40e >> [] _read_unlock_bh+0x5/0xd >> [] neigh_lookup+0x92/0x9b >> [] neigh_event_ns+0x3b/0x70 >> [] arp_process+0x1e5/0x534 >> [] dev_queue_xmit+0x279/0x29f >> [] ip_finish_output+0x1c6/0x1fc >> [] tc_classify+0x14/0x6b >> [] netif_receive_skb+0x29f/0x30e >> [] e1000_receive_skb+0x132/0x14c >> [] e1000_clean_rx_irq+0x1fa/0x29c >> [] e1000_clean+0x29f/0x427 >> [] net_rx_action+0x5c/0x14a >> [] __do_softirq+0x5d/0xc1 >> [] do_softirq+0x32/0x36 >> [] irq_exit+0x35/0x67 >> [] do_IRQ+0x73/0x82 >> [] common_interrupt+0x23/0x28 >> [] mwait_idle_with_hints+0x36/0x39 >> [] mwait_idle+0x0/0xa >> [] cpu_idle+0xa8/0xc8 >> ======================= >> > > They all are. > > afacit what's happened is that someone is running __alloc_pages(..., > __GFP_ZERO) from softirq context. But the __GFP_ZERO implementation uses > KM_USER0 which cannot be used from softirq context because non-interrupt > code on this CPU might be using the same kmap slot. > > Can anyone thing of anything which recently changed in either networking > core or e1000e which would have triggered this? > > If kzalloc() or __get_free_pages(__GFP_ZERO) is not allowed from softirq then many usages are illegal. Only old stuff (commit 77d04bd957ddca9d48a664e28b40f33993f4550e, from you Andrew) Relevant part for this backtrace : (Only triggers on i386 if we have more than 1024 neighbours (512 on x86_64) (quite rare situation), so this could explain this was not noticed until now ? diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 0c86668 ..2ec8693 100644 (file) --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -284,14 +284,11 @@ static struct neighbour **neigh_hash_alloc(unsigned int entries) struct neighbour **ret; if (size <= PAGE_SIZE) { - ret = kmalloc(size, GFP_ATOMIC); + ret = kzalloc(size, GFP_ATOMIC); } else { ret = (struct neighbour **) - __get_free_pages(GFP_ATOMIC, get_order(size)); + __get_free_pages(GFP_ATOMIC|__GFP_ZERO, get_order(size)); } - if (ret) - memset(ret, 0, size); - return ret; } > I think the core MM code is being doubly dumb here. > > a) We should be able to use __GFP_ZERO from all copntexts. > > b) it's not a highmem page anyway, so we won't be using that kmap slot. > > Pawel, can you please confirm that this: > > --- a/arch/x86/mm/highmem_32.c~a > +++ a/arch/x86/mm/highmem_32.c > @@ -73,15 +73,15 @@ void *kmap_atomic_prot(struct page *page > { > enum fixed_addresses idx; > unsigned long vaddr; > - /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */ > - > - debug_kmap_atomic_prot(type); > > + /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */ > pagefault_disable(); > > if (!PageHighMem(page)) > return page_address(page); > > + debug_kmap_atomic_prot(type); > + > idx = type + KM_TYPE_NR*smp_processor_id(); > vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); > BUG_ON(!pte_none(*(kmap_pte-idx))); > _ > > fixes it? > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org