kernel panic - ip_vs_conn_hash(): request for already hashed

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: kernel panic - ip_vs_conn_hash(): request for already hashed
From: Con Tassios <ct@xxxxxxxxxxx>
Date: Fri, 23 Jun 2006 10:56:00 +1000 (EST)
Hi List,

We are running multiple LVS directors in a master/backup configuration using
keepalived.  The directors are running an SMP kernel (2.4.32) on dual CPU 
All services are LVS-DR.  ipvs_syncmaster/ipvs_syncbackup are also running on 

Occasionally the following message is logged, followed immediately by a kernel

IPVS: ip_vs_conn_hash(): request for already hashed, called from f8b69acf

I note this problem is similar to the one described at
Although the patch listed in the above URL appears to be included in kernel

Reading some of the posts in the archives, it is suggested that there may be
race conditions in LVS that can lead to kernel panics.

Is it worth switching to a non-SMP kernel?

I'm willing to apply kernel patches if any of the kernel developers on this
list want to explore this problem further.

Output from ksymoops:

Unable to handle kernel NULL pointer dereference at virtual address 00000004
*pde = 284aa001
Oops: 0002
CPU:    1
EIP:    0010:[<f8b681f1>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000000   ebx: c61c5b20   ecx: 000058fa   edx: 00000000
esi: f8b69960   edi: 00000020   ebp: 00000001   esp: f7ffbeb4
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 0, stackpage=f7ffb000)
Stack: 00000000 2304ac83 00000000 c61c5b20 f8b69993 c61c5b20 00000001 c281ce60
       00000400 00000282 c02aeb84 00000001 00000282 00000001 00000000 c01293c6
       c61c5b20 c01297bf c61c5b20 c281cee0 d67ca840 dcceb780 00000001 00000000
Call Trace:    [<f8b69993>] [<c01293c6>] [<c01297bf>] [<c0125295>]
  [<c0124ef9>] [<c010b10b>] [<c0107020>] [<c010da38>] [<c0107020>]
  [<c01070e2>] [<c01202a5>] [<c0120512>]
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; c61c5b20 <_end+5e478a8/3848ede8>
>>esi; f8b69960 <[ip_vs]ip_vs_conn_expire+0/190>
>>esp; f7ffbeb4 <_end+37c7dc3c/3848ede8>

Trace; f8b69993 <[ip_vs]ip_vs_conn_expire+33/190>
Trace; c01293c6 <update_wall_time+16/40>
Trace; c01297bf <timer_bh+1af/3d0>
Trace; c0125295 <bh_action+55/80>
Trace; c0125137 <tasklet_hi_action+67/a0>
Trace; c0124ef9 <do_softirq+d9/e0>
Trace; c010b10b <do_IRQ+fb/130>
Trace; c0107020 <default_idle+0/50>
Trace; c010da38 <call_do_IRQ+5/d>
Trace; c0107020 <default_idle+0/50>
Trace; c010704c <default_idle+2c/50>
Trace; c01070e2 <cpu_idle+52/70>
Trace; c01202a5 <call_console_drivers+65/120>
Trace; c0120512 <printk+142/180>

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!

<Prev in Thread] Current Thread [Next in Thread>