lkml.org 
[lkml]   [2009]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: WARNING: at kernel/smp.c:332 smp_call_function_many+0x38/0x1d9()
From
Date
On Wed, 2009-02-25 at 15:16 +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > > Hopefully the final version ;-)
> >
> > Started testing them in tip:core/ipi, thanks Peter!
>
> -tip testing found a new runtime warning - see it below. Config
> attached.
>
> Ingo
>
>
> [ 2.903171] calling init_kprobes+0x0/0x12f @ 1
> [ 2.945871] Kprobe smoke test started
> [ 3.018374] ------------[ cut here ]------------
> [ 3.021836] WARNING: at kernel/smp.c:332 smp_call_function_many+0x38/0x1d9()

Looking at a fresh -tip tree, that line reads:

/* FIXME: Shim for archs using old arch_send_call_function_ipi API. */

But I figure its the !irqs_disabled(), which is on line 362.

> [ 3.021836] Hardware name: HP OmniBook PC
> [ 3.021836] Modules linked in:
> [ 3.021836] Pid: 1, comm: swapper Not tainted 2.6.29-rc6-tip-01845-g9f734f8-dirty #273
> [ 3.021836] Call Trace:
> [ 3.021836] [<c013abfa>] warn_slowpath+0x79/0x8f
> [ 3.021836] [<c0160145>] smp_call_function_many+0x38/0x1d9
> [ 3.021836] [<c0160307>] smp_call_function+0x21/0x28
> [ 3.021836] [<c013f98e>] on_each_cpu+0x14/0x2d
> [ 3.021836] [<c0126206>] flush_tlb_all+0x19/0x1b
> [ 3.021836] [<c01ab3bf>] flush_tlb_kernel_range+0xd/0xf
> [ 3.021836] [<c01ab401>] vmap_debug_free_range+0x1c/0x20
> [ 3.021836] [<c01abb98>] remove_vm_area+0x28/0x67
> [ 3.021836] [<c01abc7a>] __vunmap+0x30/0xa1
> [ 3.021836] [<c01abd12>] vunmap+0x27/0x29
> [ 3.021836] [<c06a6096>] text_poke+0x12a/0x158
> [ 3.021836] [<c06a6ba1>] arch_disarm_kprobe+0x13/0x15
> [ 3.021836] [<c06a763b>] __unregister_kprobe_top+0x68/0xda
> [ 3.021836] [<c06a7852>] unregister_kretprobes+0x24/0x68
> [ 3.021836] [<c06a78ac>] unregister_kretprobe+0x16/0x18
> [ 3.021836] [<c016a664>] test_kretprobe+0x3d/0x64
> [ 3.021836] [<c016a80e>] init_test_probes+0xbd/0x131
> [ 3.021836] [<c0a68864>] init_kprobes+0x125/0x12f

Looks to be the same one we had the other day, blaming text_poke.

We did send some patches out in that thread to make vmap yell louder
when it was used under irqs_disabled.

Of course, non of that explains any of the above...

---
diff --git a/arch/x86/kernel/alternative.c
b/arch/x86/kernel/alternative.c
index 5b8394a..4c80f15 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -503,12 +503,12 @@ void *text_poke_early(void *addr, const void
*opcode, size_t len)
*/
void *__kprobes text_poke(void *addr, const void *opcode, size_t len)
{
- unsigned long flags;
char *vaddr;
int nr_pages = 2;
struct page *pages[2];
int i;

+ might_sleep();
if (!core_kernel_text((unsigned long)addr)) {
pages[0] = vmalloc_to_page(addr);
pages[1] = vmalloc_to_page(addr + PAGE_SIZE);
@@ -522,9 +522,9 @@ void *__kprobes text_poke(void *addr, const void
*opcode, size_t len)
nr_pages = 1;
vaddr = vmap(pages, nr_pages, VM_MAP, PAGE_KERNEL);
BUG_ON(!vaddr);
- local_irq_save(flags);
+ local_irq_disable();
memcpy(&vaddr[(unsigned long)addr & ~PAGE_MASK], opcode, len);
- local_irq_restore(flags);
+ local_irq_enable();
vunmap(vaddr);
sync_core();
/* Could also do a CLFLUSH here to speed up CPU recovery; but
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index fb6f599..100d9f0 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1347,6 +1347,7 @@ EXPORT_SYMBOL(vfree);
void vunmap(const void *addr)
{
BUG_ON(in_interrupt());
+ might_sleep();
__vunmap(addr, 0);
}
EXPORT_SYMBOL(vunmap);
@@ -1366,6 +1367,8 @@ void *vmap(struct page **pages, unsigned int
count,
{
struct vm_struct *area;

+ might_sleep();
+
if (count > num_physpages)
return NULL;




\
 
 \ /
  Last update: 2009-02-25 16:07    [W:0.043 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site