[SCSI] aacraid: Abort management FIBs
authorMark Haverkamp <markh@osdl.org>
Tue, 21 Nov 2006 18:40:31 +0000 (10:40 -0800)
committerJames Bottomley <jejb@mulgrave.il.steeleye.com>
Wed, 22 Nov 2006 18:29:17 +0000 (12:29 -0600)
commitd18b448fc2caf0d719bd4bd34fb1856be89c8ef7
tree58b3acc299b6182f3c2f0d58464b1680c41a6cdf
parent33524b70e8f3dd55a4ba78ad81742c7814e7b0ed
[SCSI] aacraid: Abort management FIBs

Received from Mark Salyzyn:

Add code to abort outstanding management ioctl fibs when the blinkLED recovery
is performed. This code is 'clunky' and does not have any real feedback in that
the reset could progress before the user application has gotten it's
notification of command completion. We put a schedule() call to delay just the
right amount for most cases, because we tried a spin and still managed to find
cases where we would spin forever waiting for the management application to
acknowledge the impending doom surrounding the cause of the BlinkLED. Will
cause an oops in the context of the management application if we proceed too
quickly. I view this as the lesser of many evils since currently if there are
outstanding management ioctls during a need to reset/recover the adapter, the
management application just locks up and waits forever. The best practices fix
for this problem not going to be simple or easy (at least the fixes I imagine
today); and we found a balance between the needs of the driver to proceed, and
the applications that locked or confused that would hold back the driver. I
just do not like the idea of a kernel oops in an application to deal with low
priority, sluggish or misbehaving applications.

Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
drivers/scsi/aacraid/commsup.c