Mike:
What sort of synchronization is there between scsi_remove_host and the
error-handler thread? Offhand I can see two possible problems, depending
on how the LLD is written:
1. The error handler asks the LLD to perform a reset just as the LLD
calls scsi_remove_host as part of rmmod. scsi_remove_host
returns, the LLD's remove method returns, and the LLD is unloaded
from memory while its reset routine is executing.
2. The error handler asks the LLD to perform a reset just before the
LLD calls scsi_remove_host. The LLD's remove method can't return
until the reset completes (otherwise the reset would be executing
code that is about to be unloaded, as in (1)). But the reset
can't get started until it acquires the host adapter's device
semaphore, which is owned by the rmmod thread.
(1) causes an oops and (2) causes a deadlock. Note that (1) can be
avoided by making scis_remove_host wait until the error handler thread has
exited, but that will make (2) much more likely to happen.
In general, there needs to be some way for the error handler to prevent
the LLD from being unloaded. I don't know what the best answer is. Has
anyone thought about this?
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
