Kurt Garloff wrote:
>
> On Sat, Jan 22, 2000 at 02:14:44PM -0500, Eric Youngdale wrote:
> > One of the things that has been sticking in my craw for a while is the
> > way that all of the low-level drivers currently use the io_request_lock in
> > order to provide SMP safety. There isn't anything wrong with making the
> > thing SMP safe, of course, the problem is that io_request_lock is
> > technically designed to protect the queue proper and not provide generic
> > protection for low-level drivers. Severe misuse of the thing can lead to
> > severe system performance problems. Before the queueing rewrite,
> > io_request_lock was already held by the mid-level when calling into the
> > low-level, and the low-level drivers were along for the ride.
>
> If my memory serves, too many low-level drivers were unfixed until 2.1.8x,
> so the global io_request_lock was introduced in the mid-level code. The
> low-level drivers then just had to lock in the IRQ handler (and maybe detect
> ()). I never liked this, but that was probably the only option not to delay
> 2.2 even more.
Worse, we tried to do it with driver specific locks and we got all kinds of
corruption. The major problem was that the drivers would lock against
themselves but when they called into the mid level code (especially drivers
that don't use the new_eh code) the mid level code would trash scsi commands.
Think of things like two different drivers servicing different cards on
different interrupt vectors on an SMP machine...
> > I am proposing a means by which we can get all of the low-level drivers
> > to pry their grubby little fingers off the io_request_lock. I am thinking
> > of adding a "smp_safe" flag to the host template. If this flag is not set,
> > it indicates that the low-level driver is expecting the current behavior (in
> > other words, it assumes that io_request_lock is held when each of it't
> > entrypoints is called). Defining it this way means that with no changes to
> > the low-level drivers it is possible for things to work correctly.
>
> Go ahead. I think this approach allows a smooth transition. If you want, you
> can even make it dependent on some CONFIG_SCSI_SMPLOCK option, so that one
> can easily revert to the old behaviour, if one meets problems. That would
> allow the driver's authors to test for this option and do their locking just
> when this MACRO is set. It will be ugly code (lots of ifdefs), but you'll
> have that anyway for drivers which have a unique codebase for 2.2 and 2.4
> (what many driver authors like, and so do I).
> define something which we can test on in hosts.h:
> if (SCSI_SMP_SAFE) spinlock_irqsave (&my_lock, &flags);
I'm perfectly happy with something like this. My only request is that the
driver shouldn't need to worry about locking around entry points into the mid
level code (aka, my driver shouldn't have to lock around the calls to
scsi_done() which is a distinct problem now for all non-new_eh using drivers
at least). That means the various driver->mid-level code entry points need to
do appropriate locking so that the mid level code doesn't trash itself.
--
Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
