[asterisk-bugs] [DAHDI-linux 0017669]: [patch] oops after driver is removed

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17669 
====================================================================== 
Reported By:                tzafrir
Assigned To:                sruffell
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   17669
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
JIRA:                        
Reviewboard Link:            
====================================================================== 
Date Submitted:             2010-07-18 11:37 CDT
Last Modified:              2010-08-30 01:01 CDT
====================================================================== 
Summary:                    [patch] oops after driver is removed
Description: 
The 'bind' and 'unbind' properties allow (un)binding a device to a driver
at runtime:

zavadi:~# dahdi_hardware
pci:0000:00:09.0     wcb4xxp+     1397:08b4 Junghanns QuadBRI ISDN card
zavadi:~# echo -n 0000:00:09.0  >/sys/bus/pci/drivers/wcb4xxp/unbind
zavadi:~# dahdi_hardware
pci:0000:00:09.0     wcb4xxp-     1397:08b4 Junghanns QuadBRI ISDN card
zavadi:~# echo -n 0000:00:09.0  >/sys/bus/pci/drivers/wcb4xxp/bind
zavadi:~# dahdi_hardware
pci:0000:00:09.0     wcb4xxp+     1397:08b4 Junghanns QuadBRI ISDN card

However if any of the channels used by the device had a channel that was
open at unbind time, userspace is left with invalid file handles. You'll
probably soon get something along the lines of:

wcb4xxp 0000:00:09.0: Driver unloaded.
BUG: unable to handle kernel NULL pointer dereference at 00000080
IP: [<cc98c11e>] :dahdi:dahdi_chan_ioctl+0x18/0x819
*pde = 00000000
Oops: 0000 [https://issues.asterisk.org/view.php?id=1] SMP
Modules linked in: dahdi_echocan_oslec echo ipv6 xpp_usb xpp wctdm wct4xxp
firmware_class loop parport_pc parport snd_via82xx gameport snd_ac97_codec
ac97_bus snd_pcm snd_page_alloc snd_mpu401_uart snd_seq_midi
snd_seq_midi_event serio_raw pcspkr snd_rawmidi snd_seq snd_timer
snd_seq_device psmouse snd i2c_viapro i2c_core soundcore button wcb4xxp
dahdi crc_ccitt shpchp pci_hotplug via_agp agpgart evdev ext3 jbd mbcache
dm_mirror dm_log dm_snapshot dm_mod ide_cd_mod cdrom sd_mod via82cxxx
ide_pci_generic ide_core sata_via floppy via_rhine mii ehci_hcd ata_generic
uhci_hcd usbcore libata scsi_mod dock thermal processor fan thermal_sys
[last unloaded: scsi_wait_scan]

Pid: 2827, comm: asterisk Not tainted (2.6.26-2-686
https://issues.asterisk.org/view.php?id=1)
EIP: 0060:[<cc98c11e>] EFLAGS: 00210286 CPU: 0
EIP is at dahdi_chan_ioctl+0x18/0x819 [dahdi]
EAX: ffffffff EBX: b29608d8 ECX: b29608d8 EDX: 8004da08
ESI: 8004da08 EDI: c87d2280 EBP: 00000000 ESP: c629de24
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process asterisk (pid: 2827, ti=c629c000 task=cb4a6660 task.ti=c629c000)
Stack: 00000000 00000000 00000000 00000000 00000000 00000000 8004da08
000000fe
       c87d2280 8004da08 cc98e068 ffffffff 00000009 b29608d8 b2960886
00000005
       00000000 ffffffff ffffffff c1188fc0 ca3574e0 00000001 ca3574e8
c011be2d
Call Trace:
 [<cc98e068>] dahdi_ioctl+0x1749/0x17e9 [dahdi]
 [<c011be2d>] push_rt_task+0xff/0x1ac
 [<c011bee4>] push_rt_tasks+0xa/0x10
 [<c011b733>] try_to_wake_up+0xe8/

 [<c0118511>] __wake_up_common+0x2

 [<c011a6fb>] __wake_up+0x29/0x39
 [<c013ab0a>] wake_futex+0x1c/0x26
 [<c013baa2>] do_futex+0x303/0x70e
 [<c01dd39a>] __next_cpu+0x12/0x21
 [<c011a0d3>] find_lowest_rq+0xb0/

 [<cc98c91f>] dahdi_ioctl+0x0/0x17

 [<c017e83c>] vfs_ioctl+0x1c/0x5d
 [<c017eac7>] do_vfs_ioctl+0x24a/0

 [<c017eb1f>] sys_ioctl+0x41/0x5a
 [<c0103857>] sysenter_past_esp+0x

 [<c02b0000>] quirk_ali7101_acpi+0

 =======================
Code: 00 89 95 98 05 00 00 31 f6 83 c4 60 89 f0 5b 5e 5f 5d c3 55 57 89 c7
56 89 d6 53 89 cb 83 ec 18 8b 44 24 2c 8b 2c 85 60 09 9b cc <83> bd 80 00
00 00 00 75 0f ba eb 14 00 00 b8 99 fe 98 cc e8 bd
EIP: [<cc98c11e>] dahdi_chan_ioctl+0x18/0x819 [dahdi] SS:ESP
0068:c629de24
---[ end trace 4cc6bfb9265c52fd ]---


Only tested with wcb4xxp, and not the latest, but I suspect it has not
changed recently.
====================================================================== 

---------------------------------------------------------------------- 
 (0126428) tilghman (administrator) - 2010-08-30 01:01
 https://issues.asterisk.org/view.php?id=17669#c126428 
---------------------------------------------------------------------- 
I was thinking more along the lines of what I've attached.  If there's a
tight userspace loop that refuses to accept that the channel doesn't exist,
then soon returning what it wants to hear from the kernel driver will avoid
the tight loop without introducing artificial delays in the kernel. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-30 01:01 tilghman       Note Added: 0126428                          
======================================================================