[PATCH] Oops with eject and cdrom affects 2.4 & 2.5

Zwane Mwaikambo (zwane@linux.realnet.co.sz)
Wed, 9 Jan 2002 08:12:14 +0200 (SAST)


Hi Jens, Marcelo,
Doing an "eject" with my somewhat damaged SuSE 5.3 CD gave me the
appended reproducible oops. This bug is present in both 2.4 (visual
inspection) and 2.5. Here is the code path before the oops

ide-cd.c
static
int cdrom_queue_packet_command(ide_drive_t *drive, struct packet_command
*pc)
{
<snip>
if (ide_do_drive_cmd (drive, &req, ide_wait)) { <== [1]
printk("%s: do_drive_cmd returned
stat=%02x,err=%02x\n",
drive->name, req.buffer[0],
req.buffer[1]);
/* FIXME: we should probably abort/retry or
something */
<snip>

[1] ide_do_drive_cmd returns -EIO so we end up doing the printk. Tadow!
NULL dereference because of (char *)req.buffer. Then again, this printk
seems quite redundant IMO.

Patch diffed and tested on 2.5.2-pre10, should also apply to 2.4.17+

--- linux-2.5.2-pre10/drivers/ide/ide-cd.c.orig Wed Jan 9 09:37:24 2002
+++ linux-2.5.2-pre10/drivers/ide/ide-cd.c Wed Jan 9 09:48:15 2002
@@ -1399,8 +1399,8 @@
req.flags = REQ_PC;
req.special = (char *) pc;
if (ide_do_drive_cmd (drive, &req, ide_wait)) {
- printk("%s: do_drive_cmd returned stat=%02x,err=%02x\n",
- drive->name, req.buffer[0], req.buffer[1]);
+ printk(KERN_DEBUG "%s: do_drive_cmd returned -EIO\n",
+ drive->name);
/* FIXME: we should probably abort/retry or something */
}
if (pc->stat != 0) {

Regards,
Zwane Mwaikambo

[root@mondecino root]# eject
Jan 1 02:01:25 mondecino kernel: VFS: Disk change detected on device
ide1(22,64)
Jan 1 02:01:35 mondecino kernel: hdd: irq timeout: status=0xd0 { Busy }
Unable to handle kernel NULL pointer dereference at virtual address
00000001
*pde = 0a5d5001
*pte = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c02268ae>] Not tainted
EFLAGS: 00010282
eax: fffffffb ebx: ca5d7dc0 ecx: 013de100 edx: 00000000
esi: 0000000a edi: ca5d7cec ebp: c03de138 esp: ca5d7cec
ds: 0018 es: 0018 ss: 0018
Process eject (pid: 704, stackpage=ca5d7000)
Stack: c03de138 c03de138 00002000 00000000 00000000 00000000 00000000
00000220
ffffffff 00001640 00000001 00000000 00000000 00000000 00000000
00000000
00000000 00000000 ca5d7dc0 00000000 ca5d7ca8 00000000 00000000
00000000
Call Trace: [<c022714d>] [<c02271f3>] [<c01506d5>] [<c0228a7d>]
[<c0171640>]
[<c0162ef0>] [<c0172ce7>] [<c0171640>] [<c021bfb9>] [<c0150e69>]
[<c02311c8>]
[<c02289d0>] [<c021c18e>] [<c0150f89>] [<c0151125>] [<c01472a6>]
[<c01471ad>]
[<c015478e>] [<c0147517>] [<c010910b>]

Code: 0f be 42 01 50 0f be 02 50 8d 85 34 01 00 00 50 68 40 4a 2f

>>EIP; c02268ae <cdrom_queue_packet_command+5e/f0> <=====
Trace; c022714d <cdrom_read_tocentry+7d/90>
Trace; c02271f3 <cdrom_read_toc+93/3c0>
Trace; c01506d5 <bdget+75/270>
Trace; c0228a7d <ide_cdrom_revalidate+2d/b0>
Trace; c0171640 <kstat_read_proc+180/300>
Trace; c0162ef0 <invalidate_device+50/60>
Trace; c0172ce7 <wipe_partitions+67/90>
Trace; c0171640 <kstat_read_proc+180/300>
Trace; c021bfb9 <ide_revalidate_disk+159/180>
Trace; c0150e69 <check_disk_change+79/90>
Trace; c02311c8 <cdrom_open+b8/c0>
Trace; c02289d0 <ide_cdrom_open+40/60>
Trace; c021c18e <ide_open+ce/100>
Trace; c0150f89 <do_open+b9/1c0>
Trace; c0151125 <blkdev_open+25/30>
Trace; c01472a6 <dentry_open+e6/190>
Trace; c01471ad <filp_open+4d/60>
Trace; c015478e <getname+5e/a0>
Trace; c0147517 <sys_open+47/130>
Trace; c010910b <system_call+33/38>
Code; c02268ae <cdrom_queue_packet_command+5e/f0>
00000000 <_EIP>:
Code; c02268ae <cdrom_queue_packet_command+5e/f0> <=====
0: 0f be 42 01 movsbl 0x1(%edx),%eax <=====
Code; c02268b2 <cdrom_queue_packet_command+62/f0>
4: 50 push %eax
Code; c02268b3 <cdrom_queue_packet_command+63/f0>
5: 0f be 02 movsbl (%edx),%eax
Code; c02268b6 <cdrom_queue_packet_command+66/f0>
8: 50 push %eax
Code; c02268b7 <cdrom_queue_packet_command+67/f0>
9: 8d 85 34 01 00 00 lea 0x134(%ebp),%eax
Code; c02268bd <cdrom_queue_packet_command+6d/f0>
f: 50 push %eax
Code; c02268be <cdrom_queue_packet_command+6e/f0>
10: 68 40 4a 2f 00 push $0x2f4a40

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/