Bug 128775 - ipv6 oops when killing named
ipv6 oops when killing named
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-07-29 09:58 EDT by Gerald Britton
Modified: 2015-01-04 17:08 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 00:23:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
two kernel oopses in net/ipv6/exthdrs_core.c:79 (3.94 KB, text/plain)
2004-08-21 22:16 EDT, Roy-Magne Mo
no flags Details

  None (edit)
Description Gerald Britton 2004-07-29 09:58:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

Description of problem:
Every few hours i would see these, don't know if they're related.
I've been unable to trace their cause:

icmpv6_send: addr_any/mcast source

I noticed that named nolonger responded to requests, I straced to see
where it was stuck and found:

[pid  1926] futex(0xf65c9bf8, FUTEX_WAIT, 1928, NULL <unfinished ...>
[pid  1928] futex(0x91a660c, FUTEX_WAIT, 1, NULL <unfinished ...>
[pid  1929] clock_gettime(0,  <unfinished ...>
[pid  1930] select(32, [4 21 23 24 26], [], NULL, NULL <unfinished ...>
[pid  1929] <... clock_gettime resumed> {1091108275, 172772000}) = 0
[pid  1929] futex(0x91a4460, FUTEX_WAIT, 1812052, {3227, 694484000}
<unfinished ...>

which seems to have it sleeping in select(), however these are the
file descriptors:

named   1926 named    0u   CHR        1,3           34292 /dev/null
named   1926 named    1u   CHR        1,3           34292 /dev/null
named   1926 named    2u   CHR        1,3           34292 /dev/null
named   1926 named    3u  unix 0x3ab9e280            3292 socket
named   1926 named    4r  FIFO        0,7            3294 pipe
named   1926 named    5w  FIFO        0,7            3294 pipe
named   1926 named    6r   CHR        1,8           34720 /dev/random
named   1926 named   20u  IPv4       3334             UDP
named   1926 named   21u  IPv4       3335             TCP (LIST EN)
named   1926 named   22u  IPv4       3336             UDP
named   1926 named   23u  IPv4       3337             TCP (L ISTEN)
named   1926 named   24u  IPv6       3349             UDP *:32769
named   1926 named   25u  IPv4       3359             TCP (LISTEN )
named   1926 named   26u  IPv6       3360             TCP [::1]:rndc

and notice it's not selecting on the UDP request sockets, infact it's
only listening on a smattering of the sockets.

I tried to shut it down and failed, eventually resorting to doing a
"killall -9 named" which made the system very slow for several 
seconds and caused this oops:

------------[ cut here ]------------
kernel BUG at net/ipv6/exthdrs_core.c:79!
invalid operand: 0000 [#1]
Modules linked in: radeon parport_pc lp parport autofs4 sunrpc 8139too
mii ipv6 dm_mod uhci_hcd button battery asus_acpi ac ext3 jbd raid1
CPU:    1
EIP:    0060:[<022a2de4>]    Not tainted
EFLAGS: 00010282   (2.6.6-1.435.2.3smp)
EIP is at ipv6_skip_exthdr+0x42/0xce
eax: fffffff2   ebx: 00000000   ecx: 00000002   edx: 1dae6b80
esi: 00000080   edi: 0000000c   ebp: 1dae6b80   esp: 40cffb00
ds: 007b   es: 007b   ss: 0068
Process named (pid: 1927, threadinfo=40cff000 task=40580cf0)
Stack: 40cffb33 00000900 00000028 40cffb7c 40cffc08 1dae6b80 0219b06d
       00000000 40cffbe0 4050f310 1dd6e028 00000097 1dd6e028 02116ad8
       3c274214 0219bc05 00000000 00000000 00000100 00000060 40004c00
Call Trace:
 [<0219b06d>] selinux_parse_skb_ipv6+0x7c/0xf3
 [<02116ad8>] smp_send_reschedule+0x1a/0x1b
 [<0219bc05>] selinux_ip_postroute_last+0x20b/0x21d
 [<0219b129>] selinux_parse_skb+0x45/0x69
 [<0219baf4>] selinux_ip_postroute_last+0xfa/0x21d
 [<02200b26>] loopback_xmit+0x96/0x9c
 [<0219bc39>] selinux_ipv6_postroute_last+0xf/0x13
 [<42a0a4ed>] ip6_output_finish+0x0/0xd7 [ipv6]
 [<0225cd1b>] nf_iterate+0x40/0x89
 [<42a0a4ed>] ip6_output_finish+0x0/0xd7 [ipv6]
 [<0225d073>] nf_hook_slow+0x47/0xb2
 [<42a0a4ed>] ip6_output_finish+0x0/0xd7 [ipv6]
 [<42a0873d>] ip6_output2+0x224/0x22c [ipv6]
 [<42a0a4ed>] ip6_output_finish+0x0/0xd7 [ipv6]
 [<42a0a314>] ip6_push_pending_frames+0x28c/0x360 [ipv6]
 [<42a18b22>] udp_v6_push_pending_frames+0x14e/0x16a [ipv6]
 [<42a190f1>] udpv6_sendmsg+0x5b3/0x6fd [ipv6]
 [<0228d8c6>] inet_sendmsg+0x38/0x42
 [<0224eaa4>] sock_sendmsg+0x88/0xa2
 [<0224eb5a>] sock_recvmsg+0x9c/0xb7
 [<0214fcc9>] get_user_size+0x2e/0x55
 [<022531a6>] verify_iovec+0x3e/0x71
 [<0224fffd>] sys_sendmsg+0x143/0x191
 [<0214fa0e>] rw_vm+0x242/0x26b
 [<0214fcc9>] get_user_size+0x2e/0x55
 [<02130761>] unqueue_me+0x6f/0x75
 [<021308cf>] futex_wait+0x168/0x19a
 [<0214739a>] find_extend_vma+0x12/0x51
 [<0214fa0e>] rw_vm+0x242/0x26b
 [<02250391>] sys_socketcall+0x160/0x179
 [<021239b2>] sys_gettimeofday+0x25/0x55
Code: 0f 0b 4f 00 27 09 2e 02 80 fb 2c 75 37 6a 02 8d 56 02 8d 4c

Version-Release number of selected component (if applicable):
2.6.6-1.435.2.3smp i686

How reproducible:
Didn't try

Steps to Reproduce:
I have no idea what initially caused named to lose its selected
files, so i can't easily cause the conditions again.

Additional info:
Comment 1 Roy-Magne Mo 2004-08-21 22:13:40 EDT
We're seeing this on a uniprocessor FC2 server running with
smp-kernels on a IBM eseries x335 with Intel(R) Xeon(TM) CPU 2.80GHz
and 1G of ram. Running with up-kernel hasn't caused this oops yet. The
oopsed both occurred after about 12 hour of running time. 

Seeing oopses with both 2.6.7-1.494.2.2smp and 2.6.8-1.521smp,
chrashes seems to happen consistently with named for both cases. The
server has been upgraded from rh9 to fc2. No ipv6 other than default
fc2 is running. 

ntp could be creating multicast traffic. 
Comment 2 Roy-Magne Mo 2004-08-21 22:16:09 EDT
Created attachment 102965 [details]
two kernel oopses in net/ipv6/exthdrs_core.c:79

two kernel oopses
Comment 3 Arjan van de Ven 2004-08-22 02:06:12 EDT
might be selinux related
Comment 4 James Morris 2004-08-26 10:55:48 EDT
There is a possible fix for the bug here,
Comment 5 Roy-Magne Mo 2004-09-07 18:10:26 EDT
Server seems stable with up kernel, 18 days uptime now and no error
messages logged.
Comment 6 Dave Jones 2005-04-16 00:23:48 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

Note You need to log in before you can comment on or make changes to this bug.