Messages in this thread | | | Date | Mon, 6 Oct 2003 13:08:27 +1000 | From | Paul Mackerras <> | Subject | Re: oops when removing sbp2 module |
| |
Patrick Mansfield writes:
> There is a typo on a change to the access_count check. > > Try this patch: > > --- bleed-2.5/drivers/scsi/scsi_sysfs.c-orig Mon Sep 29 12:21:09 2003 > +++ bleed-2.5/drivers/scsi/scsi_sysfs.c Mon Sep 29 16:19:22 2003 > @@ -412,7 +412,7 @@ > set_bit(SDEV_DEL, &sdev->sdev_state); > if (sdev->host->hostt->slave_destroy) > sdev->host->hostt->slave_destroy(sdev); > - if (atomic_read(&sdev->access_count)) > + if (!atomic_read(&sdev->access_count)) > device_del(&sdev->sdev_gendev); > up_write(&class->subsys.rwsem); > }
That fixes it, it no longer oopses on removing sbp2. As before I get a message saying "Device 'fw-host0' does not have a release() function, it is broken and must be fixed." I assume that is a problem with the sbp2 module.
The code in the patch looks a little worrying to me, though. Is there some lock we have taken to ensure that no other process could be modifying sdev->access_count at the same time? Also, what is to stop some other process from noticing that sdev->access_count is 0 and calling device_del(&sdev->sdev_gendev) ?
Regards, Paul. - 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/
| |