March 2020 - Alsa-devel - mailman.alsa-project.org

Applied "ASoC: jz4740-i2s: Fix divider written at incorrect offset in register" to the asoc tree
by Mark Brown 09 Mar '20

09 Mar '20

The patch ASoC: jz4740-i2s: Fix divider written at incorrect offset in register has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 9401d5aa328e64617d87abd59af1c91cace4c3e4 Mon Sep 17 00:00:00 2001 From: Paul Cercueil <paul(a)crapouillou.net> Date: Fri, 6 Mar 2020 23:29:27 +0100 Subject: [PATCH] ASoC: jz4740-i2s: Fix divider written at incorrect offset in register The 4-bit divider value was written at offset 8, while the jz4740 programming manual locates it at offset 0. Fixes: 26b0aad80a86 ("ASoC: jz4740: Add dynamic sampling rate support to jz4740-i2s") Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20200306222931.39664-2-paul@crapouillou.net Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/jz4740/jz4740-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c index 9d5405881209..434737b2b2b2 100644 --- a/sound/soc/jz4740/jz4740-i2s.c +++ b/sound/soc/jz4740/jz4740-i2s.c @@ -83,7 +83,7 @@ #define JZ_AIC_I2S_STATUS_BUSY BIT(2) #define JZ_AIC_CLK_DIV_MASK 0xf -#define I2SDIV_DV_SHIFT 8 +#define I2SDIV_DV_SHIFT 0 #define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT) #define I2SDIV_IDV_SHIFT 8 #define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT) -- 2.20.1

1 0

[PATCH Fix for Kingston HyperX Amp (0951:16d8) 0/1] snd-usb-audio: Fix Kingston HyperX Amp (0951:16d8).
by crwulff＠gmail.com 09 Mar '20

09 Mar '20

From: Chris Wulff <crwulff(a)gmail.com> The newer version of the HyperX Amp USB audio sound card appears to use two separate interfaces for controls and audio. This doesn't work well with the current linux kernel (tested with 5.4). Interface 0 has just a mute control, while interface 2 has mute and volume controls for both playback and capture. This appears to cause a couple different issues. The first is that the wrong interface is used to query most of the controls, resulting in lots of messages like this: usb 1-3: 12:0: cannot get min/max values for control 2 (id 12) The second problem is that since it is enumerated as two separate interfaces, the device gets registered and then the capture stream gets merged into the already-registered pcm device (which results in the udev events not being generated for the capture stream and no /dev/snd/pcmC#D#c file.) This patch fixes both those problems, and allows the device to be used with ALSA programs, but pulseaudio does not enumerate the capture device correctly since it is pcmC#D1c and there is no pcmC#D0c. Adding a symlink from pcmC#D0c -> pcmC#D1c fixes pulseaudio but I'm not sure exactly why pulseaudio can't find the device without it.

2 2

[PATCH] ALSA: line6: Fix endless MIDI read loop
by Takashi Iwai 09 Mar '20

09 Mar '20

The MIDI input event parser of the LINE6 driver may enter into an endless loop when the unexpected data sequence is given, as it tries to continue the secondary bytes without termination. Also, when the input data is too short, the parser returns a negative error, while the caller doesn't handle it properly. This would lead to the unexpected behavior as well. This patch addresses those issues by checking the return value correctly and handling the one-byte event in the parser properly. The bug was reported by syzkaller. Reported-by: syzbot+cce32521ee0a824c21f7(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/usb/line6/driver.c | 2 +- sound/usb/line6/midibuf.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c index b5a3f754a4f1..4f096685ed65 100644 --- a/sound/usb/line6/driver.c +++ b/sound/usb/line6/driver.c @@ -305,7 +305,7 @@ static void line6_data_received(struct urb *urb) line6_midibuf_read(mb, line6->buffer_message, LINE6_MIDI_MESSAGE_MAXLEN); - if (done == 0) + if (done <= 0) break; line6->message_length = done; diff --git a/sound/usb/line6/midibuf.c b/sound/usb/line6/midibuf.c index 8d6eefa0d936..6a70463f82c4 100644 --- a/sound/usb/line6/midibuf.c +++ b/sound/usb/line6/midibuf.c @@ -159,7 +159,7 @@ int line6_midibuf_read(struct midi_buffer *this, unsigned char *data, int midi_length_prev = midibuf_message_length(this->command_prev); - if (midi_length_prev > 0) { + if (midi_length_prev > 1) { midi_length = midi_length_prev - 1; repeat = 1; } else -- 2.16.4

1 0

Re: BUG: soft lockup in sys_exit_group
by Andrey Konovalov 09 Mar '20

09 Mar '20

On Thu, Feb 27, 2020 at 3:30 PM syzbot <syzbot+cce32521ee0a824c21f7(a)syzkaller.appspotmail.com> wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit: d6ff8147 usb: gadget: add raw-gadget interface > git tree: https://github.com/google/kasan.git usb-fuzzer > console output: https://syzkaller.appspot.com/x/log.txt?x=147a92c3e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=90a3d9bed5648419 > dashboard link: https://syzkaller.appspot.com/bug?extid=cce32521ee0a824c21f7 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147f1d09e00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c88e45e00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+cce32521ee0a824c21f7(a)syzkaller.appspotmail.com > > watchdog: BUG: soft lockup - CPU#0 stuck for 123s! [syz-executor413:1795] > Modules linked in: > irq event stamp: 35154 > hardirqs last enabled at (35153): [<ffffffff810047c1>] trace_hardirqs_on_thunk+0x1a/0x1c arch/x86/entry/thunk_64.S:41 > hardirqs last disabled at (35154): [<ffffffff810047dd>] trace_hardirqs_off_thunk+0x1a/0x1c arch/x86/entry/thunk_64.S:42 > softirqs last enabled at (33516): [<ffffffff85c00673>] __do_softirq+0x673/0x950 kernel/softirq.c:319 > softirqs last disabled at (33499): [<ffffffff811584b8>] invoke_softirq kernel/softirq.c:373 [inline] > softirqs last disabled at (33499): [<ffffffff811584b8>] irq_exit+0x178/0x1a0 kernel/softirq.c:413 > CPU: 0 PID: 1795 Comm: syz-executor413 Not tainted 5.6.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:__read_once_size include/linux/compiler.h:199 [inline] > RIP: 0010:check_kcov_mode kernel/kcov.c:155 [inline] > RIP: 0010:write_comp_data+0x17/0x70 kernel/kcov.c:208 > Code: d0 76 07 48 89 34 d1 48 89 11 c3 0f 1f 84 00 00 00 00 00 65 4c 8b 04 25 00 0f 02 00 65 8b 05 78 b1 c2 7e a9 00 01 1f 00 75 51 <41> 8b 80 b0 12 00 00 83 f8 03 75 45 49 8b 80 b8 12 00 00 45 8b 80 > RSP: 0018:ffff8881cdf77a38 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 > RAX: 0000000000000002 RBX: 0000000000000001 RCX: ffffffff8134f89f > RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000005 > RBP: ffff8881cdf77b08 R08: ffff8881ce40b100 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 > R13: 0000000000000000 R14: ffff8881ce5839c0 R15: ffff8881db233dc0 > FS: 0000000000000000(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007fe6518f0000 CR3: 0000000007021000 CR4: 00000000001406f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > csd_lock_wait kernel/smp.c:109 [inline] > smp_call_function_single+0x2df/0x3a0 kernel/smp.c:311 > smp_call_function_many_cond+0x25e/0x900 kernel/smp.c:439 > flush_tlb_others arch/x86/include/asm/paravirt.h:68 [inline] > flush_tlb_mm_range+0x1e8/0x3e0 arch/x86/mm/tlb.c:798 > tlb_flush arch/x86/include/asm/tlb.h:24 [inline] > tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:424 [inline] > tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:414 [inline] > tlb_flush_mmu+0x274/0x630 mm/mmu_gather.c:248 > tlb_finish_mmu+0x93/0x420 mm/mmu_gather.c:328 > exit_mmap+0x298/0x4d0 mm/mmap.c:3128 > __mmput kernel/fork.c:1082 [inline] > mmput+0xce/0x3d0 kernel/fork.c:1103 > exit_mm kernel/exit.c:485 [inline] > do_exit+0xaa0/0x2c50 kernel/exit.c:788 > do_group_exit+0x125/0x340 kernel/exit.c:899 > __do_sys_exit_group kernel/exit.c:910 [inline] > __se_sys_exit_group kernel/exit.c:908 [inline] > __x64_sys_exit_group+0x3a/0x50 kernel/exit.c:908 > do_syscall_64+0xb6/0x5a0 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > RIP: 0033:0x4436c8 > Code: Bad RIP value. > RSP: 002b:00007ffd45d85c48 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004436c8 > RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 > RBP: 00000000004c3e28 R08: 00000000000000e7 R09: ffffffffffffffd0 > R10: 80603de77cf35948 R11: 0000000000000246 R12: 0000000000000001 > R13: 00000000006d7f20 R14: 0000000000000000 R15: 0000000000000000 > Sending NMI from CPU 0 to CPUs 1: > NMI backtrace for cpu 1 > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:line6_midibuf_read+0x486/0xa30 sound/usb/line6/midibuf.c:215 > Code: 08 48 01 c1 48 89 0c 24 e8 97 4f 85 fc 44 89 f6 89 df e8 7d 50 85 fc 44 39 f3 0f 8d b4 02 00 00 e8 7f 4f 85 fc 48 8b 74 24 18 <48> 63 d3 48 8b 3c 24 e8 fe d2 ad fc 01 5d 10 e8 66 4f 85 fc 31 ff > RSP: 0018:ffff8881db3099e8 EFLAGS: 00000006 > RAX: ffff8881da213100 RBX: 0000000000000000 RCX: ffffffff84ba0d63 > RDX: 0000000000000100 RSI: ffff8881cdc8c81c RDI: 0000000000000004 > RBP: ffff8881d4e6b4a0 R08: ffff8881da213100 R09: ffffed103a9cd641 > R10: ffffed103a9cd640 R11: ffff8881d4e6b200 R12: 0000000000000001 > R13: 000000000000001c R14: 00000000000003e4 R15: 0000000000000001 > FS: 0000000000000000(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007fe6518f0000 CR3: 00000001cf791000 CR4: 00000000001406e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <IRQ> > line6_data_received+0x318/0x520 sound/usb/line6/driver.c:305 > __usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648 > usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713 > dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 > call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 > expire_timers kernel/time/timer.c:1449 [inline] > __run_timers kernel/time/timer.c:1773 [inline] > __run_timers kernel/time/timer.c:1740 [inline] > run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 > __do_softirq+0x21e/0x950 kernel/softirq.c:292 > invoke_softirq kernel/softirq.c:373 [inline] > irq_exit+0x178/0x1a0 kernel/softirq.c:413 > exiting_irq arch/x86/include/asm/apic.h:546 [inline] > smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 > </IRQ> > RIP: 0010:default_idle+0x28/0x300 arch/x86/kernel/process.c:696 > Code: cc cc 41 56 41 55 65 44 8b 2d 94 c9 72 7a 41 54 55 53 0f 1f 44 00 00 e8 16 bb b5 fb e9 07 00 00 00 0f 00 2d 3a 5f 53 00 fb f4 <65> 44 8b 2d 70 c9 72 7a 0f 1f 44 00 00 5b 5d 41 5c 41 5d 41 5e c3 > RSP: 0018:ffff8881da22fda8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 > RAX: 0000000000000007 RBX: ffff8881da213100 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8881da21394c > RBP: ffffed103b442620 R08: ffff8881da213100 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 > R13: 0000000000000001 R14: ffffffff87e60000 R15: 0000000000000000 > cpuidle_idle_call kernel/sched/idle.c:154 [inline] > do_idle+0x3e0/0x500 kernel/sched/idle.c:269 > cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:361 > start_secondary+0x2a4/0x390 arch/x86/kernel/smpboot.c:264 > secondary_startup_64+0xb6/0xc0 arch/x86/kernel/head_64.S:242 > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkaller(a)googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches +line6 maintainers

2 1

increase soundcard max number upper than 32, kernel ok, but alsa-lib and alsa-utils no.
by Olivier SCHMITT 08 Mar '20

08 Mar '20

Hello dear Alsa dev team members, I try to increase alsa max number of cards in default 32 to 256 for use more than 32 loopback sound card for signal processing. I have compile my kernel and also déclare in /etc/modprobe.d/alsa-base.conf more than id max value in default 31 i get a 32 it seam to work: ls /proc/asound/ card10 card12 card14 card16 card18 card20 card22 card24 card26 card28 card30 *card32 *devices lp1 lp11 lp13 lp15 lp17 lp19 lp20 *lp22 *lp4 lp6 lp8 modules pcm timers card11 card13 card15 card17 card19 card21 card23 card25 card27 card29 card31 cards lp0 lp10 lp12 lp14 lp16 lp18 lp2 lp21 lp3 lp5 lp7 lp9 oss seq version I have compile alsa-libs and alsa utils as: sudo mkdir /usr/src/alsa cd /usr/src/alsa git clone git://git.alsa-project.org/alsa-lib.git alsa-lib cd /usr/src/alsa/alsa-lib ./gitcompile --with-max-cards=256 make install git clone git://git.alsa-project.org/alsa-utils.git alsa-utils cd /usr/src/alsa/alsa-utils ./gitcompile --with-max-cards=256 make install but when i try to use aplay or speakertest with -D hw:32,0 i get: ALSA lib pcm_hw.c:1713:(_snd_pcm_hw_open) Invalid value for card Erreur d'ouverture à la lecture: -22,Invalid argument Maybe i have forgot something? Thanks in advance for reply :-)

1 0

KASAN: slab-out-of-bounds Read in resample_shrink
by syzbot 08 Mar '20

08 Mar '20

Hello, syzbot found the following crash on: HEAD commit: 63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=110662f9e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=5d2e033af114153f dashboard link: https://syzkaller.appspot.com/bug?extid=e1fe9f44fb8ecf4fb5dd compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=160e2e91e00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=125f09fde00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd(a)syzkaller.appspotmail.com ================================================================== BUG: KASAN: slab-out-of-bounds in resample_shrink+0x4cd/0x820 sound/core/oss/rate.c:160 Read of size 2 at addr ffff8880940b8a00 by task syz-executor858/9001 CPU: 0 PID: 9001 Comm: syz-executor858 Not tainted 5.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load2_noabort+0x14/0x20 mm/kasan/generic_report.c:133 resample_shrink+0x4cd/0x820 sound/core/oss/rate.c:160 rate_transfer+0x51c/0x620 sound/core/oss/rate.c:279 snd_pcm_plug_read_transfer+0x1cc/0x270 sound/core/oss/pcm_plugin.c:651 snd_pcm_oss_read2 sound/core/oss/pcm_oss.c:1460 [inline] snd_pcm_oss_read1 sound/core/oss/pcm_oss.c:1517 [inline] snd_pcm_oss_read+0x7a6/0xd70 sound/core/oss/pcm_oss.c:2741 do_loop_readv_writev fs/read_write.c:714 [inline] do_iter_read+0x4a2/0x5b0 fs/read_write.c:935 vfs_readv fs/read_write.c:1053 [inline] do_readv+0x18c/0x330 fs/read_write.c:1090 __do_sys_readv fs/read_write.c:1181 [inline] __se_sys_readv fs/read_write.c:1178 [inline] __x64_sys_readv+0x7d/0x90 fs/read_write.c:1178 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4467e9 Code: e8 0c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fe8f541ddb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000013 RAX: ffffffffffffffda RBX: 00000000006dbc28 RCX: 00000000004467e9 RDX: 0000000000000001 RSI: 0000000020395000 RDI: 0000000000000003 RBP: 00000000006dbc20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c R13: 00007ffdbf15dd2f R14: 00007fe8f541e9c0 R15: 000000000000002d Allocated by task 9001: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 __do_kmalloc_node mm/slab.c:3616 [inline] __kmalloc_node+0x4d/0x60 mm/slab.c:3623 kmalloc_node include/linux/slab.h:578 [inline] kvmalloc_node+0x85/0x110 mm/util.c:574 kvmalloc include/linux/mm.h:645 [inline] kvzalloc include/linux/mm.h:653 [inline] snd_pcm_plugin_alloc+0x167/0x760 sound/core/oss/pcm_plugin.c:70 snd_pcm_plug_alloc+0x193/0x2e0 sound/core/oss/pcm_plugin.c:129 snd_pcm_oss_change_params_locked+0x2b34/0x4350 sound/core/oss/pcm_oss.c:1024 snd_pcm_oss_change_params sound/core/oss/pcm_oss.c:1087 [inline] snd_pcm_oss_get_active_substream+0x22c/0x2a0 sound/core/oss/pcm_oss.c:1104 snd_pcm_oss_get_rate sound/core/oss/pcm_oss.c:1754 [inline] snd_pcm_oss_set_rate sound/core/oss/pcm_oss.c:1746 [inline] snd_pcm_oss_ioctl+0x1d66/0x4600 sound/core/oss/pcm_oss.c:2593 vfs_ioctl fs/ioctl.c:47 [inline] ksys_ioctl fs/ioctl.c:763 [inline] __do_sys_ioctl fs/ioctl.c:772 [inline] __se_sys_ioctl+0x113/0x190 fs/ioctl.c:770 __x64_sys_ioctl+0x7b/0x90 fs/ioctl.c:770 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 8498: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 load_elf_binary+0x2c73/0x3440 fs/binfmt_elf.c:1086 search_binary_handler+0x190/0x5e0 fs/exec.c:1662 exec_binprm fs/exec.c:1705 [inline] __do_execve_file+0x153b/0x1ca0 fs/exec.c:1825 do_execveat_common fs/exec.c:1871 [inline] do_execve fs/exec.c:1888 [inline] __do_sys_execve fs/exec.c:1964 [inline] __se_sys_execve fs/exec.c:1959 [inline] __x64_sys_execve+0x94/0xb0 fs/exec.c:1959 do_syscall_64+0xf7/0x1c0 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880940b8800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff8880940b8800, ffff8880940b8a00) The buggy address belongs to the page: page:ffffea0002502e00 refcount:1 mapcount:0 mapping:ffff8880aa400a80 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002787a08 ffffea00024147c8 ffff8880aa400a80 raw: 0000000000000000 ffff8880940b8000 0000000100000004 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880940b8900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8880940b8980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8880940b8a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8880940b8a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880940b8b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches

1 1

[RFC PATCH 0/1] Use native gpiolib inversion for jack gpios
by Tobias Schramm 08 Mar '20

08 Mar '20

This patch changes the logic used for jack gpio state inversion to utilize gpiolib inversion. Previously the gpio active state would not correspond to the plugged-in state of the jack. Since the active state of a gpio is usually defined by its purpose in a specific application I'd expect the active state to represent the jacks plug status. However, judging by the users [1], [2] of snd_soc_jack_add_gpiods the ACPI tables of some devices seem to indicate the "wrong" polarity for their jack detect gpios. I'm not entirely sure how to deal with those devices. At the moment I'd vote for inverting the gpio active level again (via gpiod_toggle_active_low) inside snd_soc_jack_add_gpios if gpio->gpiod_dev != NULL and gpio->invert is set. I'm not entirely sure about [3] either. In my opinion removing invert = 1 from ams_delta_hook_switch_gpios and adding GPIO_ACTIVE_LOW to the flags of hook_switch in [4] would be the right move here. What are your thoughts on this? Best regards, Tobias [1] /sound/soc/intel/boards/byt-max98090.c [2] /sound/soc/intel/boards/cht_bsw_max98090_ti.c [3] /sound/soc/ti/ams-delta.c [4] /arch/arm/mach-omap1/board-ams-delta.c Tobias Schramm (1): ASoC: jack: use gpiolib inversion flag for inverted gpios sound/soc/soc-jack.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 2.24.1

1 1

alsa-utils compilation error checking for snd_tplg_new in -latopology... no,configure: error: No linkable libatopology was found.
by Olivier SCHMITT 08 Mar '20

08 Mar '20

Hello dear dev team members, I just try to compile all for my ubuntu 18.04 to run more than 32 loopback. I have found something about to : -compile kernel with kconfig CONFIG_SND_MAX_CARDS=256 -compile alsa-drivers, alsa-lib, alsa-utils with gitcompile --with-max-cards=256 but when i try to compile alsa-utils i get: checking for dlopen in -ldl... yes checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread checking required libasound headers version... 1.0.27 checking for libasound headers version >= 1.0.27 (1.0.27)... found. checking for libatopology (sound headers version > 1.1.9)... yes checking for snd_ctl_open in -lasound... yes checking for snd_tplg_new in -latopology... no configure: error: No linkable libatopology was found. Can you help me? I dont found anything about this error on the web...

1 0

alsaucm could not open configuration
by GitHub issues - opened 08 Mar '20

08 Mar '20

alsa-project/alsa-ucm-conf issue #16 was opened from nicolasfella: When I run `alsaucm listcards` on my system I get: ``` ALSA lib utils.c:261:(uc_mgr_config_load) could not open configuration file /usr/share/alsa/ucm2/HDA-Intel/HDA-Intel.conf alsaucm: error failed to get card list: No such file or directory ``` happ My audio card is a `HDA Intel PCH` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/16 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

How to make ALSA relocatable in the filesystem?
by GitHub issues - edited 07 Mar '20

07 Mar '20

alsa-project/alsa-lib issue #34 was edited from probonopd: We want to bundle a private copy of ALSA with our application, so that the ALSA from the Linux distribution is not used at all. Yet it seems ALSA is relying on some absolute paths compiled in with no clear way to pass in a different location for ALSA at runtime. How to do this? Use case: As an application developer, I want to ship my application together with all dependencies. This bundle is using musl libc, ships its own musl libc and runtime, and it is intended to also run on glibc-based systems. Reference: https://github.com/mumble-voip/mumble/issues/3959#issuecomment-596095335 Issue URL : https://github.com/alsa-project/alsa-lib/issues/34 Repository URL: https://github.com/alsa-project/alsa-lib

1 0