lkml.org 
[lkml]   [2003]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.043 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site