public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Douglas Gilbert <dougg@torque.net>
Cc: lkml@krimedawg.org, linux-kernel@vger.kernel.org,
	linux-scsi@vger.kernel.org
Subject: Re: OOPS in scsi generic stuff 2.4.10-pre6
Date: Sun, 16 Sep 2001 18:22:08 +0200	[thread overview]
Message-ID: <20010916182208.B9006@suse.de> (raw)
In-Reply-To: <3BA4CB70.50B4A3AB@torque.net>
In-Reply-To: <3BA4CB70.50B4A3AB@torque.net>

On Sun, Sep 16 2001, Douglas Gilbert wrote:
> lkml@krimedawg.org <<nameless>> wrote:
> > The ksymoops output.  Let me know if there is anything else I can offer
> > to help?  This happened when ripping a cd with cdparanoia on an IDE drive
> > with the ide-scsi stuff.
> 
> ....
> 
> > >>EIP; c01b7688 <generic_unplug_device+8/30>   <=====
> > Trace; c01f8fe6 <sg_common_write+1d6/1f0>
> > Trace; c01f9bc0 <sg_cmd_done_bh+0/280>    #### bizarre
> > Trace; c01f8c16 <sg_write+256/280>
> 
> generic_unplug_device() was an addition into the sg driver
> by Jens Axboe. Under heavy stress testing I have also received
> an oops from this function.

It looks like a race in that sg_cmd_done_bh can be completed before
generic_unplug_device is called (and thus on a free'd scsi request). We
then pass an invalid queue to generic_unplug_device.

> It is there because the tentacles of the Linux block subsystem 
> have found their way into the the SCSI midlevel. The st and sg 
> drivers are proof of why this is bad design as they are char 
> devices.

Not so. The SCSI mid level should just force this unplug, or have a
special do_req that forces imediate completion (or start of execution,
rather). The unplug in sg is needed because of that.

> If the generic_unplug_device() call is removed then the
> sg driver will periodically have its commands suspended
> on the SCSI mid level queue until the block subsystem
> decides to send something to the device in question.
> This can be seconds (which isn't a pleasant thing to do
> to a cdwriter).

Because the scsi_request_fn can quit with commands on the queue. That's
a SCSI internal issue. This is not a block layer bug.

--- drivers/scsi/sg.c~	Sun Sep 16 18:17:20 2001
+++ drivers/scsi/sg.c	Sun Sep 16 18:18:44 2001
@@ -645,6 +645,7 @@
     Scsi_Request        * SRpnt;
     Sg_device           * sdp = sfp->parentdp;
     sg_io_hdr_t         * hp = &srp->header;
+    request_queue_t	* q;
 
     srp->data.cmd_opcode = cmnd[0];  /* hold opcode of command */
     hp->status = 0;
@@ -673,6 +674,7 @@
     	return -ENODEV;
     }
     SRpnt = scsi_allocate_request(sdp->device);
+    q = &SRpnt->sr_device->request_queue;
     if(SRpnt == NULL) {
     	SCSI_LOG_TIMEOUT(1, printk("sg_write: no mem\n"));
     	sg_finish_rem_req(srp);
@@ -715,7 +717,7 @@
 		(void *)SRpnt->sr_buffer, hp->dxfer_len,
 		sg_cmd_done_bh, timeout, SG_DEFAULT_RETRIES);
     /* dxfer_len overwrites SRpnt->sr_bufflen, hence need for b_malloc_len */
-    generic_unplug_device(&SRpnt->sr_device->request_queue);
+    generic_unplug_device(q);
     return 0;
 }
 
-- 
Jens Axboe


  reply	other threads:[~2001-09-16 16:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-16 15:55 OOPS in scsi generic stuff 2.4.10-pre6 Douglas Gilbert
2001-09-16 16:22 ` Jens Axboe [this message]
2001-09-16 16:55   ` Jens Axboe
2001-09-17  4:01     ` Douglas Gilbert
2001-09-17  7:59       ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2001-09-16  7:57 lkml

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010916182208.B9006@suse.de \
    --to=axboe@suse.de \
    --cc=dougg@torque.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lkml@krimedawg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox