diff options
author | Sebastian Ott <sebott@linux.vnet.ibm.com> | 2014-06-05 14:30:19 +0200 |
---|---|---|
committer | Martin Schwidefsky <schwidefsky@de.ibm.com> | 2014-06-10 10:48:30 +0200 |
commit | 0eb69a0c584d0eaec6c2b6663e03184625c3517b (patch) | |
tree | b12bec17e1646166bdbf96ab617c794e7edad6c2 /net/netrom | |
parent | 646f919e93d4371b8654c4ae801aee74a00e4a68 (diff) | |
download | linux-0eb69a0c584d0eaec6c2b6663e03184625c3517b.tar.bz2 |
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 'net/netrom')
0 files changed, 0 insertions, 0 deletions