From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET
Description of problem:
Per the PowerPath team:
The current change to the sg driver in RH3.0 update 4 is buggy and is
preventing the qualification of PowerPath with update4.
The issue is in sg_open. When obtaining the request queue spinlock,
we suggest spin_lock_irq/spin_unlock_irq should be changed to
spin_lock_irqsave/spin_unlock_irqrestore. Not doing so, improperly
restores the interrupt mask on the local CPU, and may cause the
process to be interrupted, when in fact interrupts were disabled by a
prior spinlock_irq_save on another lock. The result is a deadlock.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
The issue is in sg_open.
Created attachment 107355 [details]
patch to sg_opn for RHEL 3.0 U4
What spin lock is being held while calling sg_open?
Per the PowerPath team: "A spinlock specific to the Powerpath base
driver is being held around the call to sg_open."
Does that help or do you need further information?
Ugh. OK, tell them to fix their code. The sg_open() call is in the
open() syscall chain, is intended for user space use, and is a
function that can sleep. Holding a spinlock around this is *NOT*
allowed. The only lock that should ever be held on entry to this
function is the BKL, and that's a lock exception where
sleeping/preemption is allowed. The use of spin_lock_irq and
unlock_irq is perfectly safe/correct when the function is called
properly. Calling sg_open with a spin lock held is going to break
horribly on RHEL4 and is broken but we don't spit out BUG()'s on RHEL3.
Thanks Doug. I will relay the information to the PowerPath team and
will let you know if there are any additional questions.
Just in case anyone runs in to this problem: The issue will be fixed
in the next version of PowerPath. EMC is also preparing a hot fix for
the current version if PowerPath. Contact EMC customer suppport.
PowerPath 4.3.2 b011 is being released on April 11, 2005.