<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/sound, branch v4.9.35</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ALSA: pcm: Don't treat NULL chmap as a fatal error</title>
<updated>2017-06-29T11:00:28+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-14T14:20:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=552a14a572a21cac91d190b38ac1a8aba9730f35'/>
<id>552a14a572a21cac91d190b38ac1a8aba9730f35</id>
<content type='text'>
commit 2deaeaf102d692cb6f764123b1df7aa118a8e97c upstream.

The standard PCM chmap helper callbacks treat the NULL info-&gt;chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
always static and non-NULL.  But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected.  The user still sees the kernel
warning unnecessarily.

For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2deaeaf102d692cb6f764123b1df7aa118a8e97c upstream.

The standard PCM chmap helper callbacks treat the NULL info-&gt;chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on.  This was OK, originally it was supposed to be
always static and non-NULL.  But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected.  The user still sees the kernel
warning unnecessarily.

For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: firewire-lib: Fix stall of process context at packet error</title>
<updated>2017-06-29T11:00:28+00:00</updated>
<author>
<name>Takashi Sakamoto</name>
<email>o-takashi@sakamocchi.jp</email>
</author>
<published>2017-06-11T07:08:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8c9c55a0f5764337ff4429ae6e15c3b6a45d1124'/>
<id>8c9c55a0f5764337ff4429ae6e15c3b6a45d1124</id>
<content type='text'>
commit 4a9bfafc64f44ef83de4e00ca1b57352af6cd8c2 upstream.

At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).

ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
-&gt;snd_pcm_common_ioctl1()
  -&gt;snd_pcm_hwsync()
    -&gt;snd_pcm_stream_lock_irq
    (sound/core/pcm_lib.c)
    -&gt;snd_pcm_update_hw_ptr()
      -&gt;snd_pcm_udpate_hw_ptr0()
        -&gt;struct snd_pcm_ops.pointer()
        (sound/firewire/*)
        = Each handler on drivers in ALSA firewire stack
          (sound/firewire/amdtp-stream.c)
          -&gt;amdtp_stream_pcm_pointer()
            (drivers/firewire/core-iso.c)
            -&gt;fw_iso_context_flush_completions()
              -&gt;struct fw_card_driver.flush_iso_completion()
              (drivers/firewire/ohci.c)
              = flush_iso_completions()
                -&gt;struct fw_iso_context.callback.sc
                (sound/firewire/amdtp-stream.c)
                = in_stream_callback() or out_stream_callback()
                  -&gt;...
    -&gt;snd_pcm_stream_unlock_irq

When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.

(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
-&gt;amdtp_stream_pcm_abort()
  -&gt;snd_pcm_stop_xrun()
    -&gt;snd_pcm_stream_lock_irqsave()
    -&gt;snd_pcm_stop()
    -&gt;snd_pcm_stream_unlock_irqrestore()

The process is stalled on the CPU due to attempt to acquire recursive lock.

[  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[  562.630866] Task dump for CPU 2:
[  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
[  562.630870] Call Trace:
[  562.630876]  ? vt_console_print+0x79/0x3e0
[  562.630880]  ? msg_print_text+0x9d/0x100
[  562.630883]  ? up+0x32/0x50
[  562.630885]  ? irq_work_queue+0x8d/0xa0
[  562.630886]  ? console_unlock+0x2b6/0x4b0
[  562.630888]  ? vprintk_emit+0x312/0x4a0
[  562.630892]  ? dev_vprintk_emit+0xbf/0x230
[  562.630895]  ? do_sys_poll+0x37a/0x550
[  562.630897]  ? dev_printk_emit+0x4e/0x70
[  562.630900]  ? __dev_printk+0x3c/0x80
[  562.630903]  ? _raw_spin_lock+0x20/0x30
[  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[  562.630945]  ? poll_select_copy_remaining+0x150/0x150
[  562.630947]  ? poll_select_copy_remaining+0x150/0x150
[  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[  562.630962]  ? futex_wake+0x90/0x170
[  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[  562.630972]  ? do_vfs_ioctl+0xa3/0x610
[  562.630974]  ? vfs_read+0x11b/0x130
[  562.630976]  ? SyS_ioctl+0x79/0x90
[  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad

This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.

Suggested-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Signed-off-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4a9bfafc64f44ef83de4e00ca1b57352af6cd8c2 upstream.

At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).

ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
-&gt;snd_pcm_common_ioctl1()
  -&gt;snd_pcm_hwsync()
    -&gt;snd_pcm_stream_lock_irq
    (sound/core/pcm_lib.c)
    -&gt;snd_pcm_update_hw_ptr()
      -&gt;snd_pcm_udpate_hw_ptr0()
        -&gt;struct snd_pcm_ops.pointer()
        (sound/firewire/*)
        = Each handler on drivers in ALSA firewire stack
          (sound/firewire/amdtp-stream.c)
          -&gt;amdtp_stream_pcm_pointer()
            (drivers/firewire/core-iso.c)
            -&gt;fw_iso_context_flush_completions()
              -&gt;struct fw_card_driver.flush_iso_completion()
              (drivers/firewire/ohci.c)
              = flush_iso_completions()
                -&gt;struct fw_iso_context.callback.sc
                (sound/firewire/amdtp-stream.c)
                = in_stream_callback() or out_stream_callback()
                  -&gt;...
    -&gt;snd_pcm_stream_unlock_irq

When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.

(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
-&gt;amdtp_stream_pcm_abort()
  -&gt;snd_pcm_stop_xrun()
    -&gt;snd_pcm_stream_lock_irqsave()
    -&gt;snd_pcm_stop()
    -&gt;snd_pcm_stream_unlock_irqrestore()

The process is stalled on the CPU due to attempt to acquire recursive lock.

[  562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[  562.630861]      2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[  562.630862]      (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[  562.630866] Task dump for CPU 2:
[  562.630867] alsa-source-OXF R  running task        0  6619      1 0x00000008
[  562.630870] Call Trace:
[  562.630876]  ? vt_console_print+0x79/0x3e0
[  562.630880]  ? msg_print_text+0x9d/0x100
[  562.630883]  ? up+0x32/0x50
[  562.630885]  ? irq_work_queue+0x8d/0xa0
[  562.630886]  ? console_unlock+0x2b6/0x4b0
[  562.630888]  ? vprintk_emit+0x312/0x4a0
[  562.630892]  ? dev_vprintk_emit+0xbf/0x230
[  562.630895]  ? do_sys_poll+0x37a/0x550
[  562.630897]  ? dev_printk_emit+0x4e/0x70
[  562.630900]  ? __dev_printk+0x3c/0x80
[  562.630903]  ? _raw_spin_lock+0x20/0x30
[  562.630909]  ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[  562.630914]  ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[  562.630918]  ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[  562.630922]  ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[  562.630925]  ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[  562.630928]  ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[  562.630932]  ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[  562.630935]  ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[  562.630938]  ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[  562.630943]  ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[  562.630945]  ? poll_select_copy_remaining+0x150/0x150
[  562.630947]  ? poll_select_copy_remaining+0x150/0x150
[  562.630952]  ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[  562.630956]  ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[  562.630960]  ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[  562.630962]  ? futex_wake+0x90/0x170
[  562.630966]  ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[  562.630970]  ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[  562.630972]  ? do_vfs_ioctl+0xa3/0x610
[  562.630974]  ? vfs_read+0x11b/0x130
[  562.630976]  ? SyS_ioctl+0x79/0x90
[  562.630978]  ? entry_SYSCALL_64_fastpath+0x1e/0xad

This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.

Suggested-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Signed-off-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: Fix use-after-free at card unregistration</title>
<updated>2017-06-14T13:06:04+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-05-24T08:19:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eb8fa317cb0184f5179e29bab8c62a4a4087cd4a'/>
<id>eb8fa317cb0184f5179e29bab8c62a4a4087cd4a</id>
<content type='text'>
commit 4efda5f2130da033aeedc5b3205569893b910de2 upstream.

soc_cleanup_card_resources() call snd_card_free() at the last of its
procedure.  This turned out to lead to a use-after-free.
PCM runtimes have been already removed via soc_remove_pcm_runtimes(),
while it's dereferenced later in soc_pcm_free() called via
snd_card_free().

The fix is simple: just move the snd_card_free() call to the beginning
of the whole procedure.  This also gives another benefit: it
guarantees that all operations have been shut down before actually
releasing the resources, which was racy until now.

Reported-and-tested-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4efda5f2130da033aeedc5b3205569893b910de2 upstream.

soc_cleanup_card_resources() call snd_card_free() at the last of its
procedure.  This turned out to lead to a use-after-free.
PCM runtimes have been already removed via soc_remove_pcm_runtimes(),
while it's dereferenced later in soc_pcm_free() called via
snd_card_free().

The fix is simple: just move the snd_card_free() call to the beginning
of the whole procedure.  This also gives another benefit: it
guarantees that all operations have been shut down before actually
releasing the resources, which was racy until now.

Reported-and-tested-by: Robert Jarzmik &lt;robert.jarzmik@free.fr&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT</title>
<updated>2017-06-14T13:06:04+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T15:26:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=82ecd2f054bd778eeb97c775c915b052e2941c79'/>
<id>82ecd2f054bd778eeb97c775c915b052e2941c79</id>
<content type='text'>
commit ba3021b2c79b2fa9114f92790a99deb27a65b728 upstream.

snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ba3021b2c79b2fa9114f92790a99deb27a65b728 upstream.

snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: timer: Fix race between read and ioctl</title>
<updated>2017-06-14T13:06:04+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-06-02T13:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=66e982d8f1a1f5e151377fe37612e9151e552dc9'/>
<id>66e982d8f1a1f5e151377fe37612e9151e552dc9</id>
<content type='text'>
commit d11662f4f798b50d8c8743f433842c3e40fe3378 upstream.

The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu-&gt;ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d11662f4f798b50d8c8743f433842c3e40fe3378 upstream.

The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu-&gt;ioctl_lock in snd_timer_user_tread() for closing the
race window.

Reported-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Alexander Potapenko &lt;glider@google.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - apply STAC_9200_DELL_M22 quirk for Dell Latitude D430</title>
<updated>2017-06-07T10:07:48+00:00</updated>
<author>
<name>Alexander Tsoy</name>
<email>alexander@tsoy.me</email>
</author>
<published>2017-05-22T17:58:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7d8ef0e0bc1e25cc23f6012aacafe3b28e8c01f7'/>
<id>7d8ef0e0bc1e25cc23f6012aacafe3b28e8c01f7</id>
<content type='text'>
commit 1fc2e41f7af4572b07190f9dec28396b418e9a36 upstream.

This model is actually called 92XXM2-8 in Windows driver. But since pin
configs for M22 and M28 are identical, just reuse M22 quirk.

Fixes external microphone (tested) and probably docking station ports
(not tested).

Signed-off-by: Alexander Tsoy &lt;alexander@tsoy.me&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1fc2e41f7af4572b07190f9dec28396b418e9a36 upstream.

This model is actually called 92XXM2-8 in Windows driver. But since pin
configs for M22 and M28 are identical, just reuse M22 quirk.

Fixes external microphone (tested) and probably docking station ports
(not tested).

Signed-off-by: Alexander Tsoy &lt;alexander@tsoy.me&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: cs4271: configure reset GPIO as output</title>
<updated>2017-05-25T13:44:32+00:00</updated>
<author>
<name>Alexander Sverdlin</name>
<email>alexander.sverdlin@gmail.com</email>
</author>
<published>2017-04-29T10:19:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ece453e8b0ca45e1b36317042c8aa7f3ef59e440'/>
<id>ece453e8b0ca45e1b36317042c8aa7f3ef59e440</id>
<content type='text'>
commit 49b2e27ab9f66b0a22c21980ad8118a4038324ae upstream.

During reset "refactoring" the output configuration was lost.
This commit repairs sound on EDB93XX boards.

Fixes: 9a397f4 ("ASoC: cs4271: add regulator consumer support")
Signed-off-by: Alexander Sverdlin &lt;alexander.sverdlin@gmail.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 49b2e27ab9f66b0a22c21980ad8118a4038324ae upstream.

During reset "refactoring" the output configuration was lost.
This commit repairs sound on EDB93XX boards.

Fixes: 9a397f4 ("ASoC: cs4271: add regulator consumer support")
Signed-off-by: Alexander Sverdlin &lt;alexander.sverdlin@gmail.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda: Fix cpu lockup when stopping the cmd dmas</title>
<updated>2017-05-25T13:44:31+00:00</updated>
<author>
<name>Jeeja KP</name>
<email>jeeja.kp@intel.com</email>
</author>
<published>2017-05-10T06:21:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0251f6affb1170a3c3364651a1c2757526cbfb88'/>
<id>0251f6affb1170a3c3364651a1c2757526cbfb88</id>
<content type='text'>
commit 960013762df0a214b57f2fce655422fb52bdfd2c upstream.

Using jiffies in hdac_wait_for_cmd_dmas() to determine when to time out
when interrupts are off (snd_hdac_bus_stop_cmd_io()/spin_lock_irq())
causes hard lockup so unlock while waiting using jiffies.

---&lt;-snip-&gt;---
&lt;0&gt;[ 1211.603046] NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
&lt;4&gt;[ 1211.603047] Modules linked in: snd_hda_intel i915 vgem
&lt;4&gt;[ 1211.603053] irq event stamp: 13366
&lt;4&gt;[ 1211.603053] hardirqs last  enabled at (13365):
...
&lt;4&gt;[ 1211.603059] Call Trace:
&lt;4&gt;[ 1211.603059]  ? delay_tsc+0x3d/0xc0
&lt;4&gt;[ 1211.603059]  __delay+0xa/0x10
&lt;4&gt;[ 1211.603060]  __const_udelay+0x31/0x40
&lt;4&gt;[ 1211.603060]  snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core]
&lt;4&gt;[ 1211.603060]  ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel]
&lt;4&gt;[ 1211.603061]  snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core]
&lt;4&gt;[ 1211.603061]  azx_stop_chip+0x9/0x10 [snd_hda_codec]
&lt;4&gt;[ 1211.603061]  azx_suspend+0x72/0x220 [snd_hda_intel]
&lt;4&gt;[ 1211.603061]  pci_pm_suspend+0x71/0x140
&lt;4&gt;[ 1211.603062]  dpm_run_callback+0x6f/0x330
&lt;4&gt;[ 1211.603062]  ? pci_pm_freeze+0xe0/0xe0
&lt;4&gt;[ 1211.603062]  __device_suspend+0xf9/0x370
&lt;4&gt;[ 1211.603062]  ? dpm_watchdog_set+0x60/0x60
&lt;4&gt;[ 1211.603063]  async_suspend+0x1a/0x90
&lt;4&gt;[ 1211.603063]  async_run_entry_fn+0x34/0x160
&lt;4&gt;[ 1211.603063]  process_one_work+0x1f4/0x6d0
&lt;4&gt;[ 1211.603063]  ? process_one_work+0x16e/0x6d0
&lt;4&gt;[ 1211.603064]  worker_thread+0x49/0x4a0
&lt;4&gt;[ 1211.603064]  kthread+0x107/0x140
&lt;4&gt;[ 1211.603064]  ? process_one_work+0x6d0/0x6d0
&lt;4&gt;[ 1211.603065]  ? kthread_create_on_node+0x40/0x40
&lt;4&gt;[ 1211.603065]  ret_from_fork+0x2e/0x40

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419
Fixes: 38b19ed7f81ec ("ALSA: hda: fix to wait for RIRB &amp; CORB DMA to set")
Reported-by: Marta Lofstedt &lt;marta.lofstedt@intel.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jeeja KP &lt;jeeja.kp@intel.com&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 960013762df0a214b57f2fce655422fb52bdfd2c upstream.

Using jiffies in hdac_wait_for_cmd_dmas() to determine when to time out
when interrupts are off (snd_hdac_bus_stop_cmd_io()/spin_lock_irq())
causes hard lockup so unlock while waiting using jiffies.

---&lt;-snip-&gt;---
&lt;0&gt;[ 1211.603046] NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
&lt;4&gt;[ 1211.603047] Modules linked in: snd_hda_intel i915 vgem
&lt;4&gt;[ 1211.603053] irq event stamp: 13366
&lt;4&gt;[ 1211.603053] hardirqs last  enabled at (13365):
...
&lt;4&gt;[ 1211.603059] Call Trace:
&lt;4&gt;[ 1211.603059]  ? delay_tsc+0x3d/0xc0
&lt;4&gt;[ 1211.603059]  __delay+0xa/0x10
&lt;4&gt;[ 1211.603060]  __const_udelay+0x31/0x40
&lt;4&gt;[ 1211.603060]  snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core]
&lt;4&gt;[ 1211.603060]  ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel]
&lt;4&gt;[ 1211.603061]  snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core]
&lt;4&gt;[ 1211.603061]  azx_stop_chip+0x9/0x10 [snd_hda_codec]
&lt;4&gt;[ 1211.603061]  azx_suspend+0x72/0x220 [snd_hda_intel]
&lt;4&gt;[ 1211.603061]  pci_pm_suspend+0x71/0x140
&lt;4&gt;[ 1211.603062]  dpm_run_callback+0x6f/0x330
&lt;4&gt;[ 1211.603062]  ? pci_pm_freeze+0xe0/0xe0
&lt;4&gt;[ 1211.603062]  __device_suspend+0xf9/0x370
&lt;4&gt;[ 1211.603062]  ? dpm_watchdog_set+0x60/0x60
&lt;4&gt;[ 1211.603063]  async_suspend+0x1a/0x90
&lt;4&gt;[ 1211.603063]  async_run_entry_fn+0x34/0x160
&lt;4&gt;[ 1211.603063]  process_one_work+0x1f4/0x6d0
&lt;4&gt;[ 1211.603063]  ? process_one_work+0x16e/0x6d0
&lt;4&gt;[ 1211.603064]  worker_thread+0x49/0x4a0
&lt;4&gt;[ 1211.603064]  kthread+0x107/0x140
&lt;4&gt;[ 1211.603064]  ? process_one_work+0x6d0/0x6d0
&lt;4&gt;[ 1211.603065]  ? kthread_create_on_node+0x40/0x40
&lt;4&gt;[ 1211.603065]  ret_from_fork+0x2e/0x40

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419
Fixes: 38b19ed7f81ec ("ALSA: hda: fix to wait for RIRB &amp; CORB DMA to set")
Reported-by: Marta Lofstedt &lt;marta.lofstedt@intel.com&gt;
Suggested-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jeeja KP &lt;jeeja.kp@intel.com&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ALSA: hda - Fix deadlock of controller device lock at unbinding</title>
<updated>2017-05-14T12:00:20+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-01-02T10:37:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7aa0e14336d977101193bef85af69b203bfba24f'/>
<id>7aa0e14336d977101193bef85af69b203bfba24f</id>
<content type='text'>
commit ab949d519601880fd46e8bc1445d6a453bf2dc09 upstream.

Imre Deak reported a deadlock of HD-audio driver at unbinding while
it's still in probing.  Since we probe the codecs asynchronously in a
work, the codec driver probe may still be kicked off while the
controller itself is being unbound.  And, azx_remove() tries to
process all pending tasks via cancel_work_sync() for fixing the other
races (see commit [0b8c82190c12: ALSA: hda - Cancel probe work instead
of flush at remove]), now we may meet a bizarre deadlock:

Unbind snd_hda_intel via sysfs:
  device_release_driver() -&gt;
    device_lock(snd_hda_intel) -&gt;
      azx_remove() -&gt;
        cancel_work_sync(azx_probe_work)

azx_probe_work():
  codec driver probe() -&gt;
     __driver_attach() -&gt;
       device_lock(snd_hda_intel)

This deadlock is caused by the fact that both device_release_driver()
and driver_probe_device() take both the device and its parent locks at
the same time.  The codec device sets the controller device as its
parent, and this lock is taken before the probe() callback is called,
while the controller remove() callback gets called also with the same
lock.

In this patch, as an ugly workaround, we unlock the controller device
temporarily during cancel_work_sync() call.  The race against another
bind call should be still suppressed by the parent's device lock.

Reported-by: Imre Deak &lt;imre.deak@intel.com&gt;
Fixes: 0b8c82190c12 ("ALSA: hda - Cancel probe work instead of flush at remove")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab949d519601880fd46e8bc1445d6a453bf2dc09 upstream.

Imre Deak reported a deadlock of HD-audio driver at unbinding while
it's still in probing.  Since we probe the codecs asynchronously in a
work, the codec driver probe may still be kicked off while the
controller itself is being unbound.  And, azx_remove() tries to
process all pending tasks via cancel_work_sync() for fixing the other
races (see commit [0b8c82190c12: ALSA: hda - Cancel probe work instead
of flush at remove]), now we may meet a bizarre deadlock:

Unbind snd_hda_intel via sysfs:
  device_release_driver() -&gt;
    device_lock(snd_hda_intel) -&gt;
      azx_remove() -&gt;
        cancel_work_sync(azx_probe_work)

azx_probe_work():
  codec driver probe() -&gt;
     __driver_attach() -&gt;
       device_lock(snd_hda_intel)

This deadlock is caused by the fact that both device_release_driver()
and driver_probe_device() take both the device and its parent locks at
the same time.  The codec device sets the controller device as its
parent, and this lock is taken before the probe() callback is called,
while the controller remove() callback gets called also with the same
lock.

In this patch, as an ugly workaround, we unlock the controller device
temporarily during cancel_work_sync() call.  The race against another
bind call should be still suppressed by the parent's device lock.

Reported-by: Imre Deak &lt;imre.deak@intel.com&gt;
Fixes: 0b8c82190c12 ("ALSA: hda - Cancel probe work instead of flush at remove")
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: intel: Fix PM and non-atomic crash in bytcr drivers</title>
<updated>2017-05-03T15:36:38+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2017-04-24T12:09:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=990afef90e0817583bf9391fae2e2864438dd7dc'/>
<id>990afef90e0817583bf9391fae2e2864438dd7dc</id>
<content type='text'>
commit 6e4cac23c5a648d50b107d1b53e9c4e1120c7943 upstream.

The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry
the ignore_suspend flag, and this prevents the suspend/resume working
properly while the stream is running, since SST core code has the
check of the running streams and returns -EBUSY.  Drop these
superfluous flags for fixing the behavior.

Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE
definitions, which leads to the kernel Oops at suspend/resume like:

  BUG: scheduling while atomic: systemd-sleep/3144/0x00000003
  Call Trace:
   dump_stack+0x5c/0x7a
   __schedule_bug+0x55/0x70
   __schedule+0x63c/0x8c0
   schedule+0x3d/0x90
   schedule_timeout+0x16b/0x320
   ? del_timer_sync+0x50/0x50
   ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
   ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
   ? remove_wait_queue+0x60/0x60
   ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core]
   ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core]
   ....

This patch addresses these appropriately, too.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6e4cac23c5a648d50b107d1b53e9c4e1120c7943 upstream.

The FE setups of Intel SST bytcr_rt5640 and bytcr_rt5651 drivers carry
the ignore_suspend flag, and this prevents the suspend/resume working
properly while the stream is running, since SST core code has the
check of the running streams and returns -EBUSY.  Drop these
superfluous flags for fixing the behavior.

Also, the bytcr_rt5640 driver lacks of nonatomic flag in some FE
definitions, which leads to the kernel Oops at suspend/resume like:

  BUG: scheduling while atomic: systemd-sleep/3144/0x00000003
  Call Trace:
   dump_stack+0x5c/0x7a
   __schedule_bug+0x55/0x70
   __schedule+0x63c/0x8c0
   schedule+0x3d/0x90
   schedule_timeout+0x16b/0x320
   ? del_timer_sync+0x50/0x50
   ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
   ? sst_wait_timeout+0xa9/0x170 [snd_intel_sst_core]
   ? remove_wait_queue+0x60/0x60
   ? sst_prepare_and_post_msg+0x275/0x960 [snd_intel_sst_core]
   ? sst_pause_stream+0x9b/0x110 [snd_intel_sst_core]
   ....

This patch addresses these appropriately, too.

Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Acked-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
