Skip to contentSkip to conversation

error handling in 2.6.x

DISCUSSION Scott T. Smith 2 participants 3 messages Sep 1, 2004 SCSI

lore
Share & tools
lore
#0 lore raw

I'm modifying an error handler for a 2.6.x driver (eh_device_reset_handler and eh_bus_reset_handler) and am wondering if I can use semaphores... is it called from a user context, or is it called from a "bottom half"? Given that I see scsi_eh_%d processes on my machine, I assume it's called from a user context, but I just wanted to be sure first.

Scott

#1 lore raw

They are called from a kernel thread, so they can sleep if necessary. They are called with the host_lock held, so make sure to drop the lock before you sleep.

-Brian

Quoted 15 lines · Scott T. Smith

I'm modifying an error handler for a 2.6.x driver (eh_device_reset_handler and eh_bus_reset_handler) and am wondering if I can use semaphores... is it called from a user context, or is it called from a "bottom half"? Given that I see scsi_eh_%d processes on my machine, I assume it's called from a user context, but I just wanted to be sure first.

Scott

-
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

Signature · 3 lines
Brian King
eServer Storage I/O
IBM Linux Technology Center
#2 lore raw
Quoted 3 lines · Brian King

They are called from a kernel thread, so they can sleep if necessary. They are called with the host_lock held, so make sure to drop the lock before you sleep.

ah ok, thanks... I now see in scsi_error where it is locking host_lock. Unfortunately, I don't have the flags to go along with it, so I guess I'll just take a stab and call spin_unlock_irq and hope it isn't nested inside another spinlock. I (quickly) grepped for spin_lock within scsi*.c and none of the other locks looked important (haha famous last words!)

Scott