summaryrefslogtreecommitdiff
path: root/drivers/infiniband/ulp/srp/ib_srp.h
diff options
context:
space:
mode:
authorSebastian Ott <sebott@linux.vnet.ibm.com>2014-06-05 14:30:19 +0200
committerMartin Schwidefsky <schwidefsky@de.ibm.com>2014-06-10 10:48:30 +0200
commit0eb69a0c584d0eaec6c2b6663e03184625c3517b (patch)
treeb12bec17e1646166bdbf96ab617c794e7edad6c2 /drivers/infiniband/ulp/srp/ib_srp.h
parent646f919e93d4371b8654c4ae801aee74a00e4a68 (diff)
s390/airq: silence lockdep warning
airq_iv_(alloc|free) is called by some users with interrupts enabled and by some with interrupts disabled which leads to the following lockdep warning: [ INFO: possible irq lock inversion dependency detected ] 3.14.0-15249-gbf29b7b-dirty #25 Not tainted --------------------------------------------------------- insmod/2108 just changed the state of lock: (&(&iv->lock)->rlock){+.....}, at: [<000000000046ee3e>] airq_iv_alloc+0x62/0x228 but this lock was taken by another, HARDIRQ-READ-safe lock in the past: (&info->lock){.-.-..} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&(&iv->lock)->rlock); local_irq_disable(); lock(&info->lock); lock(&(&iv->lock)->rlock); <Interrupt> lock(&info->lock); *** DEADLOCK *** Although this is a false alarm (since each airq user consistently calls these functions from the same context) fix this by ensuring that interrupts are disabled when the airq lock is held. Reported-by: Frank Blaschka <frank.blaschka@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'drivers/infiniband/ulp/srp/ib_srp.h')
0 files changed, 0 insertions, 0 deletions