Christoph Hellwig wrote:
>As Rolf Eike Beer noted we might not actually get to the
>kthread_should_stop() because we are waiting in the semaphore forever.
>I didn't get a rmmod hang because of this, but my instrumentation showed
>the thread defitiyly didn't exit.
>
>So make sure to wake the EH thread before the kthread_stop, and to plug
>the reaming race check kthead_should_stop() a second time just before
>calling down_interruptible().
>
>
>Index: scsi-misc-2.6/drivers/scsi/hosts.c
>===================================================================
>--- scsi-misc-2.6.orig/drivers/scsi/hosts.c 2005-09-07 14:21:44.000000000
> +0200 +++ scsi-misc-2.6/drivers/scsi/hosts.c 2005-09-07 14:22:33.000000000
> +0200 @@ -226,8 +226,10 @@
> struct Scsi_Host *shost = dev_to_shost(dev);
> struct device *parent = dev->parent;
>
>- if (shost->ehandler)
>+ if (shost->ehandler) {
>+ up(shost->eh_wait);
> kthread_stop(shost->ehandler);
>+ }
> if (shost->work_q)
> destroy_workqueue(shost->work_q);
Wouldn't this hang the same way if rescheduling happens between the up() and
the kthread_stop()?
Eike
Attachment:
pgpRhIhSs5zVE.pgp
Description: PGP signature
