netdev - Re: 2.6.23.1-smp kernel panic (network-related)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20071107122319.6b342763.akpm@linux-foundation.org>
Date:	Wed, 7 Nov 2007 12:23:19 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Marek Kierdelewicz <marek@...a.pl>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: 2.6.23.1-smp  kernel panic (network-related)

(cc netdev)

> On Wed, 7 Nov 2007 17:52:11 +0100 Marek Kierdelewicz <marek@...a.pl> wrote:
> Hi there,
> 
> My company's (ISP) bussines model requires dynamic resizing of the
> client queues. It's achieved by regenerating shaping rules and loading
> then using batch mode of a tc binary. On production systems it's done
> once every 1 or 2 minutes. Unfortunately this causes smp kernels to
> panic. Non-smp kernels don't have such problems. Bug is around a long
> time. I first noticed it after migrating to shaping configs that use
> IFB, it might have been 2.6.18 "era".
> 
> Test scenario:
> 
> I've put together a test machine with configuration copied from
> production router. I'm feeding the machine with production traffic
> by means of port mirroring. Test machine has the same config as
> production one (including mac addresses), so it tries to route the
> incoming traffic.
> 
> Tested kernels were 2.6.31.1 and 2.6.20.6 (config from 2.6.20.6 is in
> attachment). Both panicked if compiled with SMP support and work stable
> otherwise. Problem occurs only with cyclic "shaping restarts". For the
> test, reload operation using "tc -b ..." was executed in an infinite
> loop. 
> 
> Box's CPU usage was approximately 15%. Panics occur with few hours -
> one day intervals.
> 
> 
> Below I attach the panic message captured via serial console:
> ----------------------------------------------------------------------
> printk: 63 messages suppressed.
> dst cache overflow
> SMP
> Modules linked in: ipt_LOG xt_hashlimit ipt_MASQUERADE ip_set_macipmap
> ip_set_ipmap xt_state w83627hf hwmon_vid eeprom ifb ipt_SET ipt_set
> ip_set ipip tunnel4 ip_gre e1000 i2c_i801 i2c_core CPU:    1 EIP:
> 0060:[<f255c08f>]    Not tainted VLI EFLAGS: 00010202   (2.6.23.1-smp
> #2) EIP is at 0xf255c08f
> eax: c196a000   ebx: 00000100   ecx: ef2f408c   edx: f3630000
> esi: f0332029   edi: f255c08c   ebp: 00000001   esp: f3631ea8
> ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
> Process tc (pid: 27695, ti=f3630000 task=f26a9560 task.ti=f3630000)
> Stack: c01280ad f26a9560 00000001 f3631eb4 c0106f57 ef2f408c f0e8c08c
> 00000031 c0495308 0000000a c0124eb6 00000046 00000000 f7657740 f3630000
> c0124f4c c180f120 c0114e62 00000000 00000000 f7bfd224 f74ed95c c01047e0
> f7bfd224 Call Trace:
>  [<c01280ad>] run_timer_softirq+0xf5/0x154
>  [<c0106f57>] profile_pc+0x21/0x4a
>  [<c0124eb6>] __do_softirq+0x5d/0xc1
>  [<c0124f4c>] do_softirq+0x32/0x36
>  [<c0114e62>] smp_apic_timer_interrupt+0x74/0x80
>  [<c01047e0>] apic_timer_interrupt+0x28/0x30
>  [<c014c82e>] remove_vma+0x1c/0x36
>  [<c014c912>] exit_mmap+0xca/0xe1
>  [<c011eedc>] mmput+0x1d/0x75
>  [<c0123688>] do_exit+0x1be/0x68a
>  [<c0123bc0>] sys_exit_group+0x0/0xd
>  [<c0103d12>] sysenter_past_esp+0x5f/0x85
>  =======================
> Code: 00 52 41 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 fa 00 00 00 ea 05 00 00 7f 00 00 00 34 a5 96 <c1> 8c
> 00 fd f3 a5 2b 09 00 d1 d8 32 c0 00 c0 55 f2 00 a0 96 c1 EIP:
> [<f255c08f>] 0xf255c08f SS:ESP 0068:f3631ea8 Kernel panic - not
> syncing: Fatal exception in interrupt
> ----------------------------------------------------------------------
> 
> 
> -- 
> Marek Kierdelewicz
> Kierownik Działu Systemów Sieciowych, KoBa
> Manager of Network Systems Department, KoBa
> tel. (85) 7406466; fax. (85) 7406467
> e-mail: admin@...a.pl
> 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html