kernel panic - ip_vs_conn_hash(): request for already hashed

[Roberto Nibali]

Con Tassios wrote:
> On Thu, 29 Jun 2006, Roberto Nibali wrote:
> 
>>> Not yet.  I've built the kernel (still SMP) and rebooted with noirqbalance
>>> as
>>> was suggested elsewhere.
>> Pesky little bugger :) ... let us know when it shows up again.
> 
> Hi List,
> 
> After an extended period of uptime, I have had another kernel panic following a
> "IPVS: ip_vs_conn_hash(): request for already hashed" error.
> 
> The kernel had been recompiled to include CONFIG_DEBUG_SLAB=y and
> CONFIG_FRAME_POINTER=y as was previously requested.  Kernel version is 2.4.32
> SMP.
> 
> 
> Output from ksymoops:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> f8b681f1
> *pde = 2cb14001
> Oops: 0002
> CPU:    1
> EIP:    0010:[<f8b681f1>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 00000000   ebx: c3545de4   ecx: 000012f3   edx: 00000000
> esi: f8b69960   edi: 00000020   ebp: f7ff9f04   esp: f7ff9e9c
> ds: 0018   es: 0018   ss: 0018
> Process swapper (pid: 0, stackpage=f7ff9000)
> Stack: 00000006 6d4bba88 00005d11 c3545de4 f8b69993 c3545de4 e4c2d424 c2823f14
>        00000286 c02ac2c4 00000001 00000286 00000000 f7ff9edc c0129196 00000001
>        c3545de4 c012959f c3545de4 c03534e0 c03534e0 e057b264 d9ab0784 00000001
> Call Trace:    [<f8b69993>] [<c0129196>] [<c012959f>] [<c0125218>] [<c01250b7>]
>   [<c0124e79>] [<c010b2f8>] [<c0107200>] [<c010dbf8>] [<c0107200>] [<c010722f>]
>   [<c01072c2>]
> Code: 89 50 04 89 02 0f b7 43 40 c7 03 00 00 00 00 c7 43 04 00 00
> 
> 
>>> EIP; f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0>   <=====
> 
>>> ebx; c3545de4 <_end+31cbb6c/38492de8>
>>> esi; f8b69960 <[ip_vs]ip_vs_conn_expire+0/190>
>>> ebp; f7ff9f04 <_end+37c7fc8c/38492de8>
>>> esp; f7ff9e9c <_end+37c7fc24/38492de8>
> 
> Trace; f8b69993 <[ip_vs]ip_vs_conn_expire+33/190>
> Trace; c0129196 <update_wall_time+16/40>
> Trace; c012959f <timer_bh+1af/3d0>
> Trace; c0125218 <bh_action+58/90>
> Trace; c01250b7 <tasklet_hi_action+67/a0>
> Trace; c0124e79 <do_softirq+e9/f0>
> Trace; c010b2f8 <do_IRQ+108/130>
> Trace; c0107200 <default_idle+0/40>
> Trace; c010dbf8 <call_do_IRQ+5/d>
> Trace; c0107200 <default_idle+0/40>
> Trace; c010722f <default_idle+2f/40>
> Trace; c01072c2 <cpu_idle+52/70>
> 
> Code;  f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0>
> 00000000 <_EIP>:
> Code;  f8b681f1 <[ip_vs]ip_vs_conn_unhash+51/a0>   <=====
>    0:   89 50 04                  mov    %edx,0x4(%eax)   <=====
> Code;  f8b681f4 <[ip_vs]ip_vs_conn_unhash+54/a0>
>    3:   89 02                     mov    %eax,(%edx)
> Code;  f8b681f6 <[ip_vs]ip_vs_conn_unhash+56/a0>
>    5:   0f b7 43 40               movzwl 0x40(%ebx),%eax
> Code;  f8b681fa <[ip_vs]ip_vs_conn_unhash+5a/a0>
>    9:   c7 03 00 00 00 00         movl   $0x0,(%ebx)
> Code;  f8b68200 <[ip_vs]ip_vs_conn_unhash+60/a0>
>    f:   c7 43 04 00 00 00 00      movl   $0x0,0x4(%ebx)
> 
>  <0>Kernel panic: Aiee, killing interrupt handler!

Darn, it's still the same oops, so I reckon this is a really BUG :). I 
have a suspect from back when I did the threshold limitation patch a 
couple of years ago. I'll try to dig out some conversation I had with 
Willy and others regarding this matter. I remember that the refcnt 
handling was not inside the bh for some reason or something similar. If 
I find the emails, I'll report back ...

Thanks for your patience,
Roberto Nibali, ratz
-- 
echo 
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc