Bug 212122 - 2.6.9-42.19.ELsmp kernel deadlock when IPv6 address is configured on an unplugged interface
2.6.9-42.19.ELsmp kernel deadlock when IPv6 address is configured on an unplu...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-25 03:58 EDT by Paul Dwyer
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-07 23:54:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix addrconf deadlock (408 bytes, patch)
2006-10-27 13:31 EDT, Neil Horman
no flags Details | Diff
patch to fix double unlock (315 bytes, patch)
2006-11-27 09:18 EST, Neil Horman
no flags Details | Diff

  None (edit)
Description Paul Dwyer 2006-10-25 03:58:39 EDT
Description of problem:
When using 2.6.9-42.19.ELsmp kernel from
http://people.redhat.com/~jbaron/rhel4/SRPMS.kernel/ kernel hangs in deadlock in
case an IPv6 address is configured on a interface which has it's cable unplugged.

Version-Release number of selected component (if applicable):
2.6.9-42.19.ELsmp

How reproducible:


Steps to Reproduce:
[root@jalmari ~]# ip link set eth1 down
[root@jalmari ~]# ip link set eth1 up
[root@jalmari ~]# mii-tool eth1
eth1: no link
[root@jalmari ~]# ip address add 2000::11/64 dev eth1
  
Actual results:
[halt sent]
SysRq : Show Regs

Pid: 3837, comm:                   ip
EIP: 0060:[<c02d39c5>] CPU: 0
EIP is at _spin_lock_bh+0x3c/0x42
EFLAGS: 00000286    Not tainted  (2.6.9-42.19.ELsmp)
EAX: cb552000 EBX: cc82f708 ECX: 9b914cf4 EDX: 0008e365
ESI: cc82f6e0 EDI: cc82f708 EBP: cfe80800 DS: 007b ES: 007b
CR0: 8005003b CR2: 09223004 CR3: 0fd17560 CR4: 000006f0
[<d0acb1e6>] addrconf_dad_stop+0x17/0x90 [ipv6]
[<d0accd6c>] addrconf_dad_start+0x84/0x90 [ipv6]
[<d0acc0e3>] inet6_addr_add+0xa6/0xc0 [ipv6]
[<d0acd3a1>] inet6_rtm_newaddr+0x0/0x5b [ipv6]
[<c02880e3>] rtnetlink_rcv+0x226/0x327
[<c0292b56>] netlink_data_ready+0x14/0x44
[<c0292263>] netlink_sendskb+0x52/0x6c
[<c0292971>] netlink_sendmsg+0x271/0x280
[<c027823d>] sock_sendmsg+0xdb/0xf7
[<c0120519>] autoremove_wake_function+0x0/0x2d
[<c027d3c2>] verify_iovec+0x76/0xc2
[<c0279988>] sys_sendmsg+0x1ee/0x23b
[<c014e82e>] handle_mm_fault+0xdc/0x193
[<c014f55e>] vma_link+0x44/0xbc
[<c0150eca>] do_brk+0x1f0/0x22a
[<c0279d8f>] sys_socketcall+0x1df/0x1fb
[<c02d4cf7>] syscall_call+0x7/0xb

Expected results:


Additional info:
Comment 1 Neil Horman 2006-10-26 07:05:50 EDT
If you have the system still available could you please provide a sysrq-t from
when the system is hung please?  It would be helpful to know which process is
holding the semaphore that the above backtrace is blocked on.  Thanks!
Comment 3 Neil Horman 2006-10-27 13:23:53 EDT
Sorry, I didn't even look at the code, I assumed that another process was
holding the lock, although, for the record, there is no patch posted to this
bug.  I'll fix it shortly though.
Comment 4 Neil Horman 2006-10-27 13:31:22 EDT
Created attachment 139597 [details]
patch to fix addrconf deadlock
Comment 8 Jason Baron 2006-11-03 16:59:29 EST
committed in stream U5 build 42.23. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

Although based on comment #7, perhaps we need to revisit this further....
Comment 11 Neil Horman 2006-11-08 10:14:54 EST
No further movement is needed, really.  The patch has been comitted.  Nokia's
observation regarding the double unlock will cause a minor gripe from the lock
validator, but no real problems.  I'm going to clean that up shortly, but as far
as this bug is concerned, the fix is in place.
Comment 15 David Miller 2006-11-23 20:45:51 EST
I think the double unlock, if it's there, is a real bug.

If we do the first unlock, another cpu grabs the lock, then we do that
second bogus unlock, this allows a third cpu into the critical section
erroneously which will corrupt data.

It's a bug, and it can very well cause corruption, so we should fix it.
Comment 16 Neil Horman 2006-11-27 08:54:08 EST
Yeah, after considering it further, I agree.  I'll look at it and post a repo
patch if the double unlock exists.
Comment 17 Neil Horman 2006-11-27 09:18:38 EST
Created attachment 142170 [details]
patch to fix double unlock

I've submitted this patch to fix the double unlock condition
Comment 18 RHEL Product and Program Management 2006-11-27 22:34:45 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 19 RHEL Product and Program Management 2006-11-27 22:34:48 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 20 Jason Baron 2006-11-29 17:28:27 EST
ok, i've integrated the patch from comment #17. A test kernel with this patch is
available from http://people.redhat.com/~jbaron/rhel4/
Comment 22 RHEL Product and Program Management 2006-12-12 11:53:36 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.
Comment 24 Jay Turner 2007-01-02 08:46:46 EST
QE ack for RHEL4.5.
Comment 28 Mike Gahagan 2007-03-28 11:44:09 EDT
Both patches are in the -51 kernel and I set an ipv6 address with the network
down with no hang.
Comment 31 Red Hat Bugzilla 2007-05-07 23:54:36 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0304.html

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