From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bartlomiej Zolnierkiewicz Subject: Re: [Bug 13399] kernel crash SONY DVD-ROM with cd Date: Wed, 10 Jun 2009 13:18:50 +0200 Message-ID: <200906101318.50244.bzolnier@gmail.com> References: <200906091712.n59HCI72026129@demeter.kernel.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: Received: from fg-out-1718.google.com ([72.14.220.158]:3681 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755883AbZFJLN7 (ORCPT ); Wed, 10 Jun 2009 07:13:59 -0400 Received: by fg-out-1718.google.com with SMTP id d23so1233786fga.17 for ; Wed, 10 Jun 2009 04:14:00 -0700 (PDT) In-Reply-To: <200906091712.n59HCI72026129@demeter.kernel.org> Content-Disposition: inline Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: bugzilla-daemon@bugzilla.kernel.org Cc: linux-ide@vger.kernel.org On Tuesday 09 June 2009 19:12:18 bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13399 > > > > > > --- Comment #18 from Hans de Bruin 2009-06-09 17:12:18 --- > Created an attachment (id=21831) > --> (http://bugzilla.kernel.org/attachment.cgi?id=21831) > debug1 dmesg Hans, thanks for the debug data! ide-cd: ide_cd_queue_pc: cmd[0]: 0x51, write: 0x0, timeout: 1750, cmd_flags: 0x8000 ide-cd: ide_cd_do_request: cmd: 0x51, block: 18446744073709551615 ide_cd_do_request: dev hda: type=a, flags=108a640 sector 18446744073709551615, nr/cnr 0/0 bio (null), biotail (null), buffer (null), data ffff88011b849ba0, len 2 ide-cd: cdrom_do_block_pc: rq->cmd[0]: 0x51, rq->cmd_type: 0xa ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x58, thislen: 2 ide-cd: ide_cd_check_ireason: ireason: 0x2, rw: 0x0 ide-cd: cdrom_newpc_intr: data transfer, rq->cmd_type: 0xa, ireason: 0x2 ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x50, thislen: 0 ide-cd: ide_cd_request_sense_fixup: rq->cmd[0]: 0x51 #3 ide-cd: ide_cd_queue_pc: cmd[0]: 0x51, write: 0x0, timeout: 1750, cmd_flags: 0x8000 ide-cd: ide_cd_do_request: cmd: 0x51, block: 18446744073709551615 ide_cd_do_request: dev hda: type=a, flags=108a640 sector 18446744073709551615, nr/cnr 0/0 bio (null), biotail (null), buffer (null), data ffff88011b849ba0, len 32 ide-cd: cdrom_do_block_pc: rq->cmd[0]: 0x51, rq->cmd_type: 0xa ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x58, thislen: 30 ide-cd: ide_cd_check_ireason: ireason: 0x2, rw: 0x0 ide-cd: cdrom_newpc_intr: data transfer, rq->cmd_type: 0xa, ireason: 0x2 ide-cd: cdrom_newpc_intr: cmd: 0x51, write: 0x0 ide-cd: cdrom_newpc_intr: DRQ: stat: 0x50, thislen: 2 ide-cd: ide_cd_request_sense_fixup: rq->cmd[0]: 0x51 #3 BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 The above command sequence corresponds to requests generated by drivers/cdrom/cdrom.c::cdrom_get_disc_info() /* set up command and get the disc info */ init_cdrom_command(&cgc, di, sizeof(*di), CGC_DATA_READ); cgc.cmd[0] = GPCMD_READ_DISC_INFO; cgc.cmd[8] = cgc.buflen = 2; cgc.quiet = 1; if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; /* not all drives have the same disc_info length, so requeue * packet with the length the drive tells us it can supply */ buflen = be16_to_cpu(di->disc_information_length) + sizeof(di->disc_information_length); if (buflen > sizeof(disc_information)) buflen = sizeof(disc_information); cgc.cmd[8] = cgc.buflen = buflen; if ((ret = cdo->generic_packet(cdi, &cgc))) return ret; and we are hitting BUG because of the limitation of block layer, only rq->bio requests can be partially completed: int __blk_end_request(struct request *rq, int error, unsigned int nr_bytes) { if (rq->bio && __end_that_request_first(rq, error, nr_bytes)) return 1; add_disk_randomness(rq->rq_disk); end_that_request_last(rq, error); return 0; } so on error we complete the request fully instead of partially and later we try to complete the already freed request. Borislav, there are actually two issues here to investigate: * seems like we need to check for rq->bio before calling ide_cd_error_cmd() to make the regression go away (IOW we shouldn't don't do partial "good" completions for !rq->bio requests) * potentially revise our strategy of handling GPCMD_READ_DISC_INFO packet command returning less data than requested (in this particular case we ask for 32 bytes, device gives us only 30 bytes but returns good status)