[ Martin - just a heads up that I'm not applying 62, so don't make new IDE
patches relative to that ]
On Mon, 13 May 2002, Martin Dalecki wrote:
>
> Well on the channel level they are safe modulo cmd640 and rz1000.
> We can handle them by serializing them on the global lock
> in do_ide_request. Like:
>
> if (ch->drive[0].serialized|| ch->drive[1].serialized)
> then
> spin_lock(serialize_lock);
NO.
The whole point of having a per-queue lock pointer is that this should be
initialized at queue creation time. Don't add more crud to the IDE
locking, we want to get _rid_ of the locking that IDE has thought
(traditionally incorrectly) that it could do better than the higher
levels.
So when you create the queue, you should decide at THAT point whether you
just want to pass in the same lock or not.
For a cmd640, you make sure that both queues get created with the same
lock. And for non-broken chipsets, you use per-queue locks.
And then you make sure that nobody EVER uses any other lock than the queue
lock.
Linus
-
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/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:21 EST