I made available yesterday a preliminary ncr53c8xx patch against 2.1.95
that contains per controller SMP locking. My thought was that I did follow
all recommendations I heard and read about this topic.
However, looking at the current SCSI code, it seems to me that my changes
are essentially broken because the current SCSI code does very weird
things with spin_locking.
In brief, the way the io_request_lock is handled seems to me a lot ugly
and I think that it disallows to fine-grain low-level drivers.
On the other hand, some internal routines do unlocking and so are silently
assumed to be called with some lock set. Bad news for maintainance!
It is indeed not optimal but not broken to call low-level drivers
entry points with the io_request_lock set, but assuming that callbacks
needs this lock to be held is ugly requirement IMHO.
Each driver level should be responsible of its resources threading
strategy and must not rely _explicitaly_ on other level spinlock stuff.
Could you confirm me that I just have to spinlock the io_request_lock
before calling 'scsi_done' in order not to break the current SMP SCSI
requirements ? Thanks.
Regards, Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu