Re: percpu crash on NetBurst

[Tejun Heo]

Hello, Avi.

On Sun, Aug 07, 2011 at 06:32:35PM +0300, Avi Kivity wrote:
> qemu, under some conditions (-cpu host or -cpu kvm64), erroneously
> passes family=15 as the virtual cpuid.  This causes a BUG() in
> percpu code during late boot:
> 
> ------------[ cut here ]------------
> kernel BUG at mm/percpu.c:577!

This means that free_percpu() was passed a pointer which doesn't point
to the start of an allocated area.  ie. the caller is trying to free
invalid pointer.  Hmmmm... from the backtrace, it seems to be caused
by super_block->s_files.  Weird.

>  [<ffffffff811060cc>] free_percpu+0x8c/0x140
>  [<ffffffff811462a5>] __put_super+0x45/0x80
>  [<ffffffff811463d5>] put_super+0x25/0x40
>  [<ffffffff8114651a>] deactivate_locked_super+0x5a/0x70
>  [<ffffffff81146f0e>] deactivate_super+0x4e/0x70
>  [<ffffffff811614e5>] mntput_no_expire+0xb5/0x100
>  [<ffffffff8116154f>] mntput+0x1f/0x30
>  [<ffffffff81245855>] mq_put_mnt+0x15/0x20
>  [<ffffffff81245f77>] put_ipc_ns+0x47/0xa0
>  [<ffffffff81080232>] free_nsproxy+0x42/0x90
>  [<ffffffff81080440>] switch_task_namespaces+0x50/0x60
>  [<ffffffff81080460>] exit_task_namespaces+0x10/0x20
>  [<ffffffff8105d29c>] do_exit+0x46c/0x870
>  [<ffffffff8105da02>] do_group_exit+0x42/0xa0
>  [<ffffffff8105da77>] sys_exit_group+0x17/0x20
>  [<ffffffff81521382>] system_call_fastpath+0x16/0x1b
> Code: e7 41 89 54 24 14 e8 f2 fd ff ff 5b 41 5c 41 5d 41 5e 5d c3 31
> f6 31 db e9 f5 fe ff ff 45 31 ed 31 c9 31 db e9 02 ff ff ff 0f 0b
> <0f> 0b 55 48 89 e5 48 83 ec 20 48 89 5d e0 4c 89 65 e8 4c 89 6d
> RIP  [<ffffffff8110603e>] pcpu_free_area+0x17e/0x180
>  RSP <ffff880001cabd18>
> ---[ end trace 87bc11c05d27169e ]---
> 
> I traced this to the kernel cpuid code determining the cache line size:
> 
> arch/x86/kernel/cpu/intel.c:
> 
>     if (c->x86 == 15)
>         c->x86_cache_alignment = c->x86_clflush_size * 2;
> 
> If I comment out this code, the kernel boots and all is well.
> 
> I suspect that the percpu code sometimes uses x86_cache_alignment
> and sometimes some hardcoded macro; I saw some negative elements of
> chunk->map[].

The negative elements indicate allocated areas.

> All this applies to v3.0; current upstream (c2f340a69ca) fails even
> worse, haven't yet determined exactly why.
> 
> I'm surprised this hasn't been reported before; Ingo, don't you have
> family=15 hosts in your test farm?

Hmmm... I can't trigger the problem w/ kvm64 (I tried mounting and
unmounting filesystems but it worked okay) and am quite skeptical this
is a wide spread problem given that the percpu core code is used very
widely and hasn't seen a lot of changes lately.  Is there anything
specific you need to do to trigger the condition?  Can you try to
print out the s_files addresses being allocated and freed?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/