On systems where a ccw based console device is used a lockdep false alarm
could be triggered when a device driver calls printk while holding a
subchannels lock (e.g. in it's irq handler). Since this is valid behavior
fix this by introducing a separate lock class for the console subchannels
lock.
The lockdep warning was revealed by "printk: enable interrupts before calling
console_trylock_for_printk()" which changed console_unlock() to be called with
lockdep enabled.
[ INFO: possible recursive locking detected ]
3.15.0-rc5-next-20140520 #1 Not tainted
---------------------------------------------
ccwgroup/2239 is trying to acquire lock:
(&(sch->lock)->rlock){-.-...}, at: [<0000000000642a52>] raw3215_write+0x52/0x200
but task is already holding lock:
(&(sch->lock)->rlock){-.-...}, at: [<00000000005fd160>] do_cio_interrupt+0x60/0x108
other info that might help us debug this:
Possible unsafe locking scenario:
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>