summaryrefslogtreecommitdiff
path: root/net/unix/af_unix.c
diff options
context:
space:
mode:
authorTakashi Iwai <tiwai@suse.de>2016-01-18 13:52:47 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2016-01-31 11:28:57 -0800
commitdafa57ee81748f6a6950c06f19a160d0a209795e (patch)
treee001d234b764488d011fc447d29530e0ef96735d /net/unix/af_unix.c
parent1d8e11540fc94fc98c9d6215737e20eff514e376 (diff)
ALSA: hrtimer: Fix stall by hrtimer_cancel()
commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream. hrtimer_cancel() waits for the completion from the callback, thus it must not be called inside the callback itself. This was already a problem in the past with ALSA hrtimer driver, and the early commit [fcfdebe70759: ALSA: hrtimer - Fix lock-up] tried to address it. However, the previous fix is still insufficient: it may still cause a lockup when the ALSA timer instance reprograms itself in its callback. Then it invokes the start function even in snd_timer_interrupt() that is called in hrtimer callback itself, results in a CPU stall. This is no hypothetical problem but actually triggered by syzkaller fuzzer. This patch tries to fix the issue again. Now we call hrtimer_try_to_cancel() at both start and stop functions so that it won't fall into a deadlock, yet giving some chance to cancel the queue if the functions have been called outside the callback. The proper hrtimer_cancel() is called in anyway at closing, so this should be enough. Reported-and-tested-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions