April 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: hda/realtek: Enable audio line out on ASUS D640SA
by Jian-Hong Pan 08 Apr '18

08 Apr '18

This ASUS D640SA desktop whose mother board is D640MB has - two jacks which are a headphone and a mic on the front panel, - three jacks which are a mic, a line out and a line in on the rear panel - one internal speaker. If I plug a headphone to the front headphone jack, there will be sound through the headphone jack, and no sound through the internal speaker. If I unplug the headphone from the the headphone jack, there will be sound through the internal speaker. And always no sound through rear line out, when I plug a headphone or an externel speaker to the rear line out jack. Besides, I had checked and toggled the Auto-Mute Mode in alsamixer, but the rear line out still was not working. Then I checked the sound settings in GUI, and found there was no "Line Out" could be chosen, only the "Headphones" and "HDMI/DisplayPort". However, system does know that there is an "Intel PCH Line Out". [ 10.089082] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC887-VD: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [ 10.089083] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=1 (0x1a/0x0/0x0/0x0/0x0) [ 10.089084] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 10.089085] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 10.089086] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 10.089087] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 10.089088] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 10.089089] snd_hda_codec_realtek hdaudioC0D0: Line=0x15 [ 10.104387] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9 [ 10.104416] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10 [ 10.104441] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input11 [ 10.104467] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12 [ 10.104494] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13 Consequently, I checked the pin widgets' default configuration values: - Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Pin Default 0x01014010: [Jack] Line Out at Ext Rear - Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Pin Default 0x02214030: [Jack] HP Out at Ext Front Because the headphone jack (Node ID:0x1b) locates on the desktop's front panel, not rear panel, I change the headphone jack's configuration from primary chassis to separate chassis. So, the configuration value of Node ID:0x1b should be 0x22214030. Additionally, I toggle the Auto-Mute Mode of Realtek codecs to “Speaker Only” which makes signal outputs through line out jack when the "Line Out" is chosen in the sound settings. Signed-off-by: Jian-Hong Pan <jian-hong(a)endlessm.com> --- sound/pci/hda/patch_realtek.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index aef1f52db7d9..a066d84c6478 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1810,6 +1810,8 @@ enum { ALC887_FIXUP_BASS_CHMAP, ALC1220_FIXUP_GB_DUAL_CODECS, ALC1220_FIXUP_CLEVO_P950, + ALC887_FIXUP_ASUS_AUTOMUTE_MODE, + ALC887_FIXUP_ASUS_FRONT_HP, }; static void alc889_fixup_coef(struct hda_codec *codec, @@ -2044,6 +2046,24 @@ static void alc1220_fixup_clevo_p950(struct hda_codec *codec, snd_hda_override_conn_list(codec, 0x1b, 1, conn1); } +/* fix the default Auto-Mute Mode in mixer */ +static void alc887_fixup_asus_automute_mode(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct snd_kcontrol *kctl; + struct snd_ctl_elem_value *uctl; + + kctl = snd_hda_find_mixer_ctl(codec, "Auto-Mute Mode"); + if (!kctl) + return; + uctl = kzalloc(sizeof(*uctl), GFP_KERNEL); + if (!uctl) + return; + uctl->value.enumerated.item[0] = 1; + kctl->put(kctl, uctl); + kfree(uctl); +} + static const struct hda_fixup alc882_fixups[] = { [ALC882_FIXUP_ABIT_AW9D_MAX] = { .type = HDA_FIXUP_PINS, @@ -2288,6 +2308,19 @@ static const struct hda_fixup alc882_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc1220_fixup_clevo_p950, }, + [ALC887_FIXUP_ASUS_AUTOMUTE_MODE] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc887_fixup_asus_automute_mode, + }, + [ALC887_FIXUP_ASUS_FRONT_HP] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + {0x1b, 0x22214030}, + {} + }, + .chained = true, + .chain_id = ALC887_FIXUP_ASUS_AUTOMUTE_MODE, + }, }; static const struct snd_pci_quirk alc882_fixup_tbl[] = { @@ -2321,6 +2354,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x13c2, "Asus A7M", ALC882_FIXUP_EAPD), SND_PCI_QUIRK(0x1043, 0x1873, "ASUS W90V", ALC882_FIXUP_ASUS_W90V), SND_PCI_QUIRK(0x1043, 0x1971, "Asus W2JC", ALC882_FIXUP_ASUS_W2JC), + SND_PCI_QUIRK(0x1043, 0x2160, "ASUSPRO D640MB", ALC887_FIXUP_ASUS_FRONT_HP), SND_PCI_QUIRK(0x1043, 0x835f, "Asus Eee 1601", ALC888_FIXUP_EEE1601), SND_PCI_QUIRK(0x1043, 0x84bc, "ASUS ET2700", ALC887_FIXUP_ASUS_BASS), SND_PCI_QUIRK(0x1043, 0x8691, "ASUS ROG Ranger VIII", ALC882_FIXUP_GPIO3), -- 2.11.0

2 4

[alsa-devel] INFO: rcu detected stall in snd_pcm_stream_unlock_irq
by syzbot 08 Apr '18

08 Apr '18

Hello, syzbot hit the following crash on upstream commit 3fd14cdcc05a682b03743683ce3a726898b20555 (Fri Apr 6 19:15:41 2018 +0000) Merge tag 'mtd/for-4.17' of git://git.infradead.org/linux-mtd syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=584505e6ccdbedcf7629 Unfortunately, I don't have any reproducer for this crash yet. Raw console output: https://syzkaller.appspot.com/x/log.txt?id=5653573555716096 Kernel config: https://syzkaller.appspot.com/x/.config?id=-5813481738265533882 compiler: gcc (GCC) 8.0.1 20180301 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+584505e6ccdbedcf7629(a)syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. See footer for details. If you forward the report, please keep this part and the footer. random: crng init done INFO: rcu_sched self-detected stall on CPU 1-....: (124996 ticks this GP) idle=c9a/1/4611686018427387906 softirq=17918/17918 fqs=31239 (t=125000 jiffies g=9607 c=9606 q=187) NMI backtrace for cpu 1 CPU: 1 PID: 6608 Comm: syz-executor4 Not tainted 4.16.0+ #4 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 print_cpu_stall kernel/rcu/tree.c:1525 [inline] check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 __rcu_pending kernel/rcu/tree.c:3356 [inline] rcu_pending kernel/rcu/tree.c:3401 [inline] rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 update_process_times+0x2d/0x70 kernel/time/timer.c:1636 tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:171 tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1179 __run_hrtimer kernel/time/hrtimer.c:1337 [inline] __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1399 hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1457 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 </IRQ> RIP: 0010:check_kcov_mode kernel/kcov.c:67 [inline] RIP: 0010:__sanitizer_cov_trace_pc+0x20/0x50 kernel/kcov.c:101 RSP: 0018:ffff8801c82feb50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: ffff8801b5330040 RBX: 0000000000000000 RCX: 1ffff10036a6611b RDX: 0000000000000000 RSI: ffffffff859d514c RDI: ffffffff88b172b8 RBP: ffff8801c82feb50 R08: ffff8801b53308b8 R09: 0000000000000006 R10: ffff8801b5330040 R11: 0000000000000000 R12: 0000000000000004 R13: 00000000ffffffe0 R14: ffff8801d128ab00 R15: ffff8801ce80e040 snd_pcm_stream_unlock_irq+0xbc/0xf0 sound/core/pcm_native.c:167 __snd_pcm_lib_xfer+0x739/0x1d10 sound/core/pcm_lib.c:2246 snd_pcm_oss_write3+0xe9/0x220 sound/core/oss/pcm_oss.c:1236 snd_pcm_oss_write2+0x34c/0x460 sound/core/oss/pcm_oss.c:1373 snd_pcm_oss_sync1+0x332/0x5a0 sound/core/oss/pcm_oss.c:1606 snd_pcm_oss_sync.isra.29+0x790/0x980 sound/core/oss/pcm_oss.c:1682 snd_pcm_oss_release+0x214/0x290 sound/core/oss/pcm_oss.c:2559 __fput+0x34d/0x890 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1e4/0x290 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1aee/0x2730 kernel/exit.c:865 do_group_exit+0x16f/0x430 kernel/exit.c:968 get_signal+0x886/0x1960 kernel/signal.c:2469 do_signal+0x98/0x2040 arch/x86/kernel/signal.c:810 exit_to_usermode_loop+0x28a/0x310 arch/x86/entry/common.c:162 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline] syscall_return_slowpath arch/x86/entry/common.c:265 [inline] do_syscall_64+0x792/0x9d0 arch/x86/entry/common.c:292 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x455259 RSP: 002b:00007f20e223bce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 000000000072c038 RCX: 0000000000455259 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000072c038 RBP: 000000000072c038 R08: 0000000000000000 R09: 000000000072c010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000a3e81f R14: 00007f20e223c9c0 R15: 0000000000000002 --- This bug is generated by a dumb bot. It may contain errors. See https://goo.gl/tpsmEJ for details. Direct all questions to syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. If you forgot to add the Reported-by tag, once the fix for this bug is merged into any tree, please reply to this email with: #syz fix: exact-commit-title To mark this as a duplicate of another syzbot report, please reply with: #syz dup: exact-subject-of-another-report If it's a one-off invalid bug report, please reply with: #syz invalid Note: if the crash happens again, it will cause creation of a new bug report. Note: all commands must start from beginning of the line in the email body.

1 0

Re: [alsa-devel] [PATCH 14/15] ARM: pxa: change SSP devices allocation
by Robert Jarzmik 08 Apr '18

08 Apr '18

Arnd Bergmann <arnd(a)arndb.de> writes: chop chop ... removed several mail recipients to leave only the ASoC / PXA subset ... > On Mon, Apr 2, 2018 at 4:26 PM, Robert Jarzmik <robert.jarzmik(a)free.fr> wrote: > >> >> +static struct pxa_ssp_info pxa_ssp_infos[] = { >> + { .dma_chan_rx_name = "ssp1_rx", .dma_chan_tx_name = "ssp1_tx", }, >> + { .dma_chan_rx_name = "ssp1_rx", .dma_chan_tx_name = "ssp1_tx", }, >> + { .dma_chan_rx_name = "ssp2_rx", .dma_chan_tx_name = "ssp2_tx", }, >> + { .dma_chan_rx_name = "ssp2_rx", .dma_chan_tx_name = "ssp2_tx", }, >> + { .dma_chan_rx_name = "ssp3_rx", .dma_chan_tx_name = "ssp3_tx", }, >> + { .dma_chan_rx_name = "ssp3_rx", .dma_chan_tx_name = "ssp3_tx", }, >> + { .dma_chan_rx_name = "ssp4_rx", .dma_chan_tx_name = "ssp4_tx", }, >> + { .dma_chan_rx_name = "ssp4_rx", .dma_chan_tx_name = "ssp4_tx", }, >> +}; > > This part looks odd to me, you're adding an extra level of indirection to > do two stages of lookups in some form of platform data. That's unfortunately right. > Why can't you just always use "rx" and "tx" as the names here? Well I couldn't. I'll explain you why, and maybe you'll find a better solution. That all is related to how ASoC and SSP interact. If I remember correctly, here is how it works : - the DMA channel is requested in sound/arm/pxa2xx-pcm-lib.c:128 return snd_dmaengine_pcm_open( substream, dma_request_slave_channel(rtd->platform->dev, The trick is that the device here is _not_ the SSP one, it's if memory serves me well the pxa-pcm-audio one. As a consequence, the device cannot be used to differenciate which SSP exactly is providing the sound samples stream. This information is nevertheless required to choose the correct requestor line, which is a 1-to-1 match to the SSP port. The indirection in the channel name is used to choose the correct requestor line for a given SSP port providing the samples. It also must be underlined that this dma request serves both AC97 and SSP as sample providers. > (also, I don't see why each line is duplicated, but I'm sure there's > an easy answer for that). Ahh that is an unfortunate rebase most probably :) Cheers. -- Robert

2 4

[alsa-devel] [PATCH] slimbus: Fix out-of-bounds access in slim_slicesize()
by Geert Uytterhoeven 08 Apr '18

08 Apr '18

With gcc-4.1.2: slimbus/messaging.c: In function ‘slim_slicesize’: slimbus/messaging.c:186: warning: statement with no effect Indeed, clamp() is a macro not operating in-place, but returning the clamped value. Hence the value is not clamped at all, which may lead to an out-of-bounds access. Fix this by assigning the clamped value. Fixes: afbdcc7c384b0d44 ("slimbus: Add messaging APIs to slimbus framework") Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> --- drivers/slimbus/messaging.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/slimbus/messaging.c b/drivers/slimbus/messaging.c index 884419c37e8419c8..457ea1f8db309cb9 100644 --- a/drivers/slimbus/messaging.c +++ b/drivers/slimbus/messaging.c @@ -183,7 +183,7 @@ static u16 slim_slicesize(int code) 0, 1, 2, 3, 3, 4, 4, 5, 5, 5, 5, 6, 6, 6, 6, 7 }; - clamp(code, 1, (int)ARRAY_SIZE(sizetocode)); + code = clamp(code, 1, (int)ARRAY_SIZE(sizetocode)); return sizetocode[code - 1]; } -- 2.7.4

1 0

[alsa-devel] [PATCH v2 1/3] dell-led: Change dell-led.h to dell-common.h
by Kai-Heng Feng 07 Apr '18

07 Apr '18

This header will be used for more than just led. Change it to a more generic name. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- v2: Mario suggested to squash the HDA part into the same series. drivers/platform/x86/dell-laptop.c | 2 +- include/linux/{dell-led.h => dell-common.h} | 4 ++-- sound/pci/hda/dell_wmi_helper.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) rename include/linux/{dell-led.h => dell-common.h} (61%) diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c index c52c6723374b..8ba820e6c3d0 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -29,7 +29,7 @@ #include <linux/mm.h> #include <linux/i8042.h> #include <linux/debugfs.h> -#include <linux/dell-led.h> +#include <linux/dell-common.h> #include <linux/seq_file.h> #include <acpi/video.h> #include "dell-rbtn.h" diff --git a/include/linux/dell-led.h b/include/linux/dell-common.h similarity index 61% rename from include/linux/dell-led.h rename to include/linux/dell-common.h index 92521471517f..37e4b614dd74 100644 --- a/include/linux/dell-led.h +++ b/include/linux/dell-common.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __DELL_LED_H__ -#define __DELL_LED_H__ +#ifndef __DELL_COMMON_H__ +#define __DELL_COMMON_H__ int dell_micmute_led_set(int on); diff --git a/sound/pci/hda/dell_wmi_helper.c b/sound/pci/hda/dell_wmi_helper.c index 1b48a8c19d28..56050cc3c0ee 100644 --- a/sound/pci/hda/dell_wmi_helper.c +++ b/sound/pci/hda/dell_wmi_helper.c @@ -4,7 +4,7 @@ */ #if IS_ENABLED(CONFIG_DELL_LAPTOP) -#include <linux/dell-led.h> +#include <linux/dell-common.h> enum { MICMUTE_LED_ON, -- 2.15.1

6 24

Re: [alsa-devel] INFO: rcu detected stall in snd_pcm_oss_write3 (2)
by syzbot 07 Apr '18

07 Apr '18

syzbot has found reproducer for the following crash on upstream commit 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +0000) Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=150189c103427d31a053 So far this crash happened 15 times on upstream. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5405588854931456 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=5561439796330496 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=5697900571000832 Kernel config: https://syzkaller.appspot.com/x/.config?id=-5813481738265533882 compiler: gcc (GCC) 8.0.1 20180301 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+150189c103427d31a053(a)syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. IPVS: ftp: loaded support on port[0] = 21 INFO: rcu_sched self-detected stall on CPU 1-....: (124999 ticks this GP) idle=622/1/4611686018427387906 softirq=10596/10596 fqs=31239 (t=125000 jiffies g=4952 c=4951 q=20) NMI backtrace for cpu 1 CPU: 1 PID: 4474 Comm: syzkaller631460 Not tainted 4.16.0+ #3 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 print_cpu_stall kernel/rcu/tree.c:1525 [inline] check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 __rcu_pending kernel/rcu/tree.c:3356 [inline] rcu_pending kernel/rcu/tree.c:3401 [inline] rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 update_process_times+0x2d/0x70 kernel/time/timer.c:1636 tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:171 tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1179 __run_hrtimer kernel/time/hrtimer.c:1337 [inline] __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1399 hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1457 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 </IRQ> RIP: 0010:__snd_pcm_lib_xfer+0x768/0x1d10 sound/core/pcm_lib.c:2111 RSP: 0018:ffff8801b7b76ea8 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000000 RBX: ffffffffffffffe0 RCX: ffffed0036f6edec RDX: 0000000000000000 RSI: ffffffff859ff04e RDI: ffffed0036f6edf0 RBP: ffff8801b7b77148 R08: ffff8801afeae9b8 R09: 0000000000000006 R10: ffff8801afeae140 R11: 0000000000000000 R12: 0000000000000004 R13: 00000000ffffffe0 R14: ffff8801af2165c0 R15: ffff8801ceaec000 snd_pcm_oss_write3+0xe9/0x220 sound/core/oss/pcm_oss.c:1236 io_playback_transfer+0x274/0x310 sound/core/oss/io.c:47 snd_pcm_plug_write_transfer+0x36c/0x470 sound/core/oss/pcm_plugin.c:619 snd_pcm_oss_write2+0x25c/0x460 sound/core/oss/pcm_oss.c:1365 snd_pcm_oss_sync1+0x332/0x5a0 sound/core/oss/pcm_oss.c:1606 snd_pcm_oss_sync.isra.29+0x790/0x980 sound/core/oss/pcm_oss.c:1682 snd_pcm_oss_release+0x214/0x290 sound/core/oss/pcm_oss.c:2559 __fput+0x34d/0x890 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1e4/0x290 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1aee/0x2730 kernel/exit.c:865 do_group_exit+0x16f/0x430 kernel/exit.c:968 SYSC_exit_group kernel/exit.c:979 [inline] SyS_exit_group+0x1d/0x20 kernel/exit.c:977 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x4446e9 RSP: 002b:00007ffe29466408 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00000000004446e9 RDX: 00000000004446e9 RSI: 0000000000000080 RDI: 0000000000000001 RBP: 00000000006cf018 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000401ff0 R13: 0000000000402080 R14: 0000000000000000 R15: 0000000000000000

3 4

Re: [alsa-devel] INFO: rcu detected stall in snd_pcm_stream_lock_irq
by Dmitry Vyukov 07 Apr '18

07 Apr '18

On Fri, Apr 6, 2018 at 3:24 PM, syzbot <syzbot+74e011b2046f4322d178(a)syzkaller.appspotmail.com> wrote: > Hello, > > syzbot hit the following crash on upstream commit > 38c23685b273cfb4ccf31a199feccce3bdcb5d83 (Fri Apr 6 04:29:35 2018 +0000) > Merge tag 'armsoc-drivers' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > syzbot dashboard link: > https://syzkaller.appspot.com/bug?extid=74e011b2046f4322d178 > > Unfortunately, I don't have any reproducer for this crash yet. > Raw console output: > https://syzkaller.appspot.com/x/log.txt?id=4582053840420864 > Kernel config: > https://syzkaller.appspot.com/x/.config?id=-5813481738265533882 > compiler: gcc (GCC) 8.0.1 20180301 (experimental) +ALSA maintainers This was misattributed to kcov.c, I will fix it. > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+74e011b2046f4322d178(a)syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > syz-executor1 (6140) used greatest stack depth: 11720 bytes left > INFO: rcu_sched self-detected stall on CPU > 1-....: (124998 ticks this GP) idle=0b2/1/4611686018427387906 > softirq=15730/15730 fqs=31205 > (t=125000 jiffies g=8316 c=8315 q=1529) > NMI backtrace for cpu 1 > CPU: 1 PID: 6087 Comm: syz-executor0 Not tainted 4.16.0+ #3 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > <IRQ> > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x1b9/0x294 lib/dump_stack.c:113 > nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103 > nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62 > arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 > trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline] > rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376 > print_cpu_stall kernel/rcu/tree.c:1525 [inline] > check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593 > __rcu_pending kernel/rcu/tree.c:3356 [inline] > rcu_pending kernel/rcu/tree.c:3401 [inline] > rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763 > update_process_times+0x2d/0x70 kernel/time/timer.c:1636 > tick_sched_handle+0xa0/0x180 kernel/time/tick-sched.c:171 > tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1179 > __run_hrtimer kernel/time/hrtimer.c:1337 [inline] > __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1399 > hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1457 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline] > smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862 > </IRQ> > RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x50 kernel/kcov.c:106 > RSP: 0018:ffff8801920cf4d0 EFLAGS: 00000216 ORIG_RAX: ffffffffffffff13 > RAX: 0000000000040000 RBX: ffff8801ceb61200 RCX: ffffc90001eb0000 > RDX: 0000000000040000 RSI: ffffffff859d760f RDI: ffff8801ceb61200 > RBP: ffff8801920cf4d0 R08: ffff8801b4946540 R09: 0000000000000006 > R10: ffff8801b4946540 R11: 0000000000000000 R12: ffffffff8826fa20 > R13: 0000000000000020 R14: ffff8801d3008c00 R15: ffff8801ceb61200 > snd_pcm_stream_lock_irq+0xf/0xf0 sound/core/pcm_native.c:150 > __snd_pcm_lib_xfer+0x345/0x1d10 sound/core/pcm_lib.c:2162 > snd_pcm_oss_write3+0xe9/0x220 sound/core/oss/pcm_oss.c:1236 > io_playback_transfer+0x274/0x310 sound/core/oss/io.c:47 > snd_pcm_plug_write_transfer+0x36c/0x470 sound/core/oss/pcm_plugin.c:619 > snd_pcm_oss_write2+0x25c/0x460 sound/core/oss/pcm_oss.c:1365 > snd_pcm_oss_write1 sound/core/oss/pcm_oss.c:1431 [inline] > snd_pcm_oss_write+0x55f/0xa20 sound/core/oss/pcm_oss.c:2774 > do_loop_readv_writev fs/read_write.c:703 [inline] > do_iter_write+0x491/0x5f0 fs/read_write.c:961 > vfs_writev+0x1c7/0x330 fs/read_write.c:1004 > do_writev+0x112/0x2f0 fs/read_write.c:1039 > SYSC_writev fs/read_write.c:1112 [inline] > SyS_writev+0x27/0x30 fs/read_write.c:1109 > do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287 > entry_SYSCALL_64_after_hwframe+0x42/0xb7 > RIP: 0033:0x4552d9 > RSP: 002b:00007f82ef52cc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 > RAX: ffffffffffffffda RBX: 00007f82ef52d6d4 RCX: 00000000004552d9 > RDX: 0000000000000001 RSI: 0000000020000180 RDI: 0000000000000015 > RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff > R13: 00000000000006cc R14: 00000000006fd3c0 R15: 0000000000000000 > > > --- > This bug is generated by a dumb bot. It may contain errors. > See https://goo.gl/tpsmEJ for details. > Direct all questions to syzkaller(a)googlegroups.com. > > syzbot will keep track of this bug report. > If you forgot to add the Reported-by tag, once the fix for this bug is > merged > into any tree, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup: exact-subject-of-another-report > If it's a one-off invalid bug report, please reply with: > #syz invalid > Note: if the crash happens again, it will cause creation of a new bug > report. > Note: all commands must start from beginning of the line in the email body.

2 2

[alsa-devel] [PATCH 1/2] ALSA: pcm: Yet finer pending signal check in OSS read/write loop
by Takashi Iwai 07 Apr '18

07 Apr '18

PCM OSS emulation has the nested inner loops, and the loops in snd_pcm_oss_read3() and write3() have no pending signal check, so potentially they can hog for too long time for processing. Add the extra check there. While we're at it, a slight code cleanup using the standard macro for the PCM state check is used. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/oss/pcm_oss.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c index 481ab0e94ffa..5e009a444d9d 100644 --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1221,8 +1221,7 @@ snd_pcm_sframes_t snd_pcm_oss_write3(struct snd_pcm_substream *substream, const struct snd_pcm_runtime *runtime = substream->runtime; int ret; while (1) { - if (runtime->status->state == SNDRV_PCM_STATE_XRUN || - runtime->status->state == SNDRV_PCM_STATE_SUSPENDED) { + if (!snd_pcm_running(substream)) { #ifdef OSS_DEBUG pcm_dbg(substream->pcm, "pcm_oss: write: recovering from %s\n", @@ -1241,6 +1240,8 @@ snd_pcm_sframes_t snd_pcm_oss_write3(struct snd_pcm_substream *substream, const /* has not been started */ if (runtime->status->state == SNDRV_PCM_STATE_PREPARED) return -EAGAIN; + if (signal_pending(current)) + return -ERESTARTSYS; } return ret; } @@ -1278,10 +1279,11 @@ snd_pcm_sframes_t snd_pcm_oss_read3(struct snd_pcm_substream *substream, char *p if (ret < 0) break; } - continue; - } - if (ret != -ESTRPIPE) + } else if (ret != -ESTRPIPE) { break; + } + if (signal_pending(current)) + return -ERESTARTSYS; } return ret; } -- 2.16.3

1 2

[alsa-devel] [PATCH v3 0/3] ALSA: usb-audio: Minor refactoring and UAC3 fix
by Takashi Iwai 07 Apr '18

07 Apr '18

Hi, this is a v3 patchset, addressing the silly mistakes in validator functions in the previous patchset. Takashi === v1->v2: Rename the helper function to be more specific Make validators to check sizes more strictly v2->v3: Fix clock selector validator v2 and v3 as suggested by Ruslan Takashi Iwai (3): ALSA: usb-audio: Refactor clock finder helpers ALSA: usb-audio: More strict sanity checks for clock parsers ALSA: usb-audio: Add sanity checks in UAC3 clock parsers sound/usb/clock.c | 128 +++++++++++++++++++++++------------------------------- 1 file changed, 54 insertions(+), 74 deletions(-) -- 2.16.2

2 9

[alsa-devel] [PATCH] ALSA: pcm: Fix endless loop for XRUN recovery in OSS emulation
by Takashi Iwai 07 Apr '18

07 Apr '18

The commit 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") split the PCM preparation code to a locked version, and it added a sanity check of runtime->oss.prepare flag along with the change. This leaded to an endless loop when the stream gets XRUN: namely, snd_pcm_oss_write3() and co call snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and the loop continues until the PCM state reaches to another one. As the function is supposed to execute the preparation unconditionally, drop the invalid state check there. The bug was triggered by syzkaller. Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Reported-by: syzbot+7e3f31a52646f939c052(a)syzkaller.appspotmail.com Reported-by: syzbot+4f2016cf5185da7759dc(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/oss/pcm_oss.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c index 481ab0e94ffa..727647755aab 100644 --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1128,13 +1128,12 @@ static int snd_pcm_oss_get_active_substream(struct snd_pcm_oss_file *pcm_oss_fil } /* call with params_lock held */ +/* NOTE: this doesn't care whether runtime->oss.prepare is set or not */ static int snd_pcm_oss_prepare(struct snd_pcm_substream *substream) { int err; struct snd_pcm_runtime *runtime = substream->runtime; - if (!runtime->oss.prepare) - return 0; err = snd_pcm_kernel_ioctl(substream, SNDRV_PCM_IOCTL_PREPARE, NULL); if (err < 0) { pcm_dbg(substream->pcm, -- 2.16.3

1 0