]> www.infradead.org Git - users/jedix/linux-maple.git/commit
ALSA: pcm: Fix lockdep warning with nonatomic PCM ops
authorTakashi Iwai <tiwai@suse.de>
Fri, 17 Jul 2015 13:22:33 +0000 (15:22 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 10 Aug 2015 19:21:53 +0000 (12:21 -0700)
commit898dbc106e50ab6de4106e2415d0f40e260903c4
tree3f4bed88b289a7b205822e0dd797a96348740b91
parent2b16e01ae6b5c0c5e1f382fcad51a3053270374a
ALSA: pcm: Fix lockdep warning with nonatomic PCM ops

commit 67756e3191c90e7c0b94b8b2fb63de255b6cd337 upstream.

With the nonatomic PCM ops, the system may spew lockdep warnings like:

 =============================================
 [ INFO: possible recursive locking detected ]
 4.2.0-rc1-jeejaval3 #12 Not tainted
 ---------------------------------------------
 aplay/4029 is trying to acquire lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fd473>] snd_pcm_stream_lock+0x43/0x60

 but task is already holding lock:
  (snd_pcm_link_rwsem){.+.+.+}, at: [<ffffffff816fcf29>] snd_pcm_action_nonatomic+0x29/0x80

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(snd_pcm_link_rwsem);
   lock(snd_pcm_link_rwsem);

Although this is false-positive as the rwsem is taken always as
read-only for these code paths, it's certainly annoying to see this at
any occasion.  A simple fix is to use down_read_nested() in
snd_pcm_stream_lock() that can be called inside another lock.

Reported-by: Vinod Koul <vinod.koul@intel.com>
Reported-by: Jeeja Kp <jeeja.kp@intel.com>
Tested-by: Jeeja Kp <jeeja.kp@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sound/core/pcm_native.c