Bug 2400 - when release disconnected usb cdrom device, kernel oops
Summary: when release disconnected usb cdrom device, kernel oops
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: USB (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Greg Kroah-Hartman
URL:
Keywords:
Depends on:
Blocks: USB
  Show dependency tree
 
Reported: 2004-03-30 19:02 UTC by Young-Ho Cha
Modified: 2006-04-22 15:11 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.5-rc3
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Patch to fix problem (4.21 KB, patch)
2004-04-02 17:09 UTC, James Bottomley
Details | Diff

Description Young-Ho Cha 2004-03-30 19:02:31 UTC
Distribution: Gentoo Linux 1.4
Hardware Environment: Athlon-xp 2500+, M/B based NForce2 chipset, LG 52x ATA
CD-ROM with usb case.
Software Environment: 
Problem Description:
I opened cdrom device file with python, and disconnect cdrom.
then close device file, kernel oops happened.
i think cdo reference invalid pointer(not NULL) in cdrom_release() 
this is kernel dmesg with enable cdrom debug option and print cdi, cdo pointer

cdrom: entering register_cdrom
cdrom: drive "/dev/sr1" registered
cdrom: entering cdrom_open
cdrom: entering open_for_data
cdrom: drive_status=4
cdrom: entering cdrom_count_tracks
cdrom: track 1: format=2, ctrl=4
cdrom: disc has 1 tracks: 0=audio 1=data 0=Cd-I 0=XA
cdrom: all seems well, opening the device.
cdrom: opening the device gave me 0.
cdrom: device opened successfully.
cdrom: Use count for "/dev/sr1" now 1
cdrom: entering unregister_cdrom
cdrom: drive "/dev/sr1" unregistered
cdrom: entering cdrom_release
cdi = cd6ba898
cdo = ffffffff
cdrom: Use count for "/dev/" now zero

and this is oops message.
Unable to handle kernel NULL pointer dereference at virtual address 00000033
 printing eip:
f8d42302
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU:    0
EIP:    0060:[<f8d42302>]    Tainted: PF
EFLAGS: 00010246   (2.6.5-rc3)
EIP is at cdrom_release+0x62/0x140 [cdrom]
eax: 00000029   ebx: cd6ba898   ecx: 00000001   edx: 00000000
esi: 00000000   edi: df267800   ebp: ffffffff   esp: ce6b1f38
ds: 007b   es: 007b   ss: 0068
Process python (pid: 25490, threadinfo=ce6b0000 task=cf992280)
Stack: f8d47368 cd6ba8bc c015d3fc f73b3780 f73b37d0 df267800 f73b378c c015e5dc
       cd6ba898 00000000 00000000 ed318780 c015e610 f7ff4ec0 f7765080 c0156735
       f73b3780 ed318780 f7764b80 ed318780 00000000 e68df680 ce6b0000 c0154cf9
Call Trace:
 [<c015d3fc>] kill_bdev+0x3c/0x50
 [<c015e5dc>] blkdev_put+0x17c/0x1b0
 [<c015e610>] blkdev_close+0x0/0x40
 [<c0156735>] __fput+0x115/0x130
 [<c0154cf9>] filp_close+0x59/0x90
 [<c0154d91>] sys_close+0x61/0xa0
 [<c01089f5>] sysenter_past_esp+0x52/0x71
 
Code: f6 45 34 04 74 28 a1 88 9f d4 f8 85 c0 75 1f 83 3d 84 9f d4

Steps to reproduce:
1. connect usb cdrom device with some media
2. run python interpreter
3. python> fp = open('/dev/sr1')
4. disconnect usb cdrom
5. python> fp.close()
6. kernel oops happen.
Comment 1 James Bottomley 2004-04-02 17:09:43 UTC
Created attachment 2485 [details]
Patch to fix problem

Please try this, it should fix the problem
Comment 2 Young-Ho Cha 2004-04-05 19:32:59 UTC
after apply patch and boot, this oops happened.

----
Unable to handle kernel paging request at virtual address 7366767c
 printing eip:
f8c85085
*pde = 00000000
Oops: 0000 [#1]
PREEMPT
CPU:    0
EIP:    0060:[<f8c85085>]    Not tainted VLI
EFLAGS: 00010296   (2.6.5-mm1)
EIP is at sr_cd_check+0xf5/0x470 [sr_mod]
eax: 73667630   ebx: f73ede34   ecx: 00000000   edx: 00000001
esi: f70f9b00   edi: c0416000   ebp: f70f9b18   esp: f73ede1c
ds: 007b   es: 007b   ss: 0068
Process hald (pid: 9201, threadinfo=f73ec000 task=f7c28eb0)
Stack: f70f9b00 f73ede34 0000002c 00000000 ffffff85 00000000 00000043 00000000
       0000400c c0416000 0000000c ffffff85 00000000 00000002 00000001 00007530
       00000000 00000000 00000001 f70f9b00 f70f9b18 f8c86780 f8c83089 f70f9b18
Call Trace:
 [<f8c83089>] sr_media_change+0x89/0xa0 [sr_mod]
 [<f8ceb810>] media_changed+0x60/0x90 [cdrom]
 [<f8ceb876>] cdrom_media_changed+0x36/0x40 [cdrom]
 [<c015aa86>] check_disk_change+0x36/0x90
 [<f8cead34>] cdrom_open+0x84/0xe0 [cdrom]
 [<f8c8357a>] sr_block_open+0x2a/0x30 [sr_mod]
 [<c015aca4>] do_open+0x144/0x410
 [<c015a5f0>] bdev_test+0x0/0x20
 [<c015a610>] bdev_set+0x0/0x10
 [<c015b024>] blkdev_open+0x34/0x70
 [<c01513f7>] dentry_open+0x147/0x210
 [<c01512a2>] filp_open+0x62/0x70
 [<c015173b>] sys_open+0x5b/0x90
 [<c0105a35>] sysenter_past_esp+0x52/0x71
 
Code: 0c 01 00 00 00 8b 44 24 14 80 66 14 fb 89 46 10 89 2c 24 e8 ae f5 ff ff 83
f8 64 74 0b 89 34 24 e8 d1 fb ff ff 48 74 39 8b 46 08 <81> 78 4c 00 08 00 00 74
10 c7 44 24 04 00 08 00 00 89 34 24 e8
Comment 3 Adrian Bunk 2005-12-31 01:40:53 UTC
Is this issue still present in recent 2.6 kernels?
Comment 4 Adrian Bunk 2006-04-22 09:35:01 UTC
I'm assuming this issue is already fixed in recent 2.6 kernels.

Please reopen this bug if it's still present in kernel 2.6.16.

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