ASoC: SOF: Intel: add balanced code of snd_hdac_ext_bus_device_init by bardliao · Pull Request #311 · thesofproject/linux

bardliao · 2018-11-23T08:17:12Z

snd_hdac_ext_bus_device_init is called in hda_codec_probe, it will
initialize and register the HDA extended codec. We should call
snd_hdac_ext_bus_device_remove to unregister the HDA extended codec.
Otherwise, We will fail in rmmod/modprobe cycle.

Signed-off-by: Bard liao yung-chuan.liao@linux.intel.com

bardliao · 2018-11-23T08:18:45Z

It is one reason of #144 .

lgirdwood · 2018-11-23T12:49:17Z

@keyonjie can you also take a look.

keyonjie

good catch, but let's move it to hda_dsp_remove(), where is balanced to hda_dsp_probe().

plbossart · 2018-11-26T16:03:50Z

should be the other way around, do this before hda_codec_i915_exit()

plbossart

can we make these changes conditional when HDA_LINK is enabled?
Thanks!

bardliao · 2018-11-28T12:14:58Z

@plbossart I added #if condition for snd_hdac_ext_bus_device_remove() and snd_hdac_link_free_all(). Could you review it?

plbossart

Thanks Bard!

snd_hdac_ext_bus_device_init is called in hda_codec_probe, it will initialize and register the HDA extended codec. We should call snd_hdac_ext_bus_device_remove to unregister the HDA extended codec. Also, snd_hdac_link_free_all() and snd_hdac_ext_bus_exit() are required for remove. Otherwise, We will fail in rmmod/modprobe cycle. Signed-off-by: Bard liao <yung-chuan.liao@linux.intel.com>

commit 987914a upstream. After a successful allocation of path_rec, num_paths is set to 1, but any error after such allocation will leave num_paths uncleared. This causes to de-referencing a NULL pointer later on. Hence, num_paths needs to be set back to 0 if such an error occurs. The following crash from syzkaller revealed it. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 357 Comm: syz-executor060 Not tainted 4.18.0+ thesofproject#311 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ib_copy_path_rec_to_user+0x94/0x3e0 Code: f1 f1 f1 f1 c7 40 0c 00 00 f4 f4 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 e8 d7 60 24 ff 48 8d 7b 4c 48 89 f8 48 c1 e8 03 <42> 0f b6 14 30 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 RSP: 0018:ffff88006586f980 EFLAGS: 00010207 RAX: 0000000000000009 RBX: 0000000000000000 RCX: 1ffff1000d5fe475 RDX: ffff8800621e17c0 RSI: ffffffff820d45f9 RDI: 000000000000004c RBP: ffff88006586fa50 R08: ffffed000cb0df73 R09: ffffed000cb0df72 R10: ffff88006586fa70 R11: ffffed000cb0df73 R12: 1ffff1000cb0df30 R13: ffff88006586fae8 R14: dffffc0000000000 R15: ffff88006aff2200 FS: 00000000016fc880(0000) GS:ffff88006d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000063fec000 CR4: 00000000000006b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ib_copy_path_rec_from_user+0xcc0/0xcc0 ? __mutex_unlock_slowpath+0xfc/0x670 ? wait_for_completion+0x3b0/0x3b0 ? ucma_query_route+0x818/0xc60 ucma_query_route+0x818/0xc60 ? ucma_listen+0x1b0/0x1b0 ? sched_clock_cpu+0x18/0x1d0 ? sched_clock_cpu+0x18/0x1d0 ? ucma_listen+0x1b0/0x1b0 ? ucma_write+0x292/0x460 ucma_write+0x292/0x460 ? ucma_close_id+0x60/0x60 ? sched_clock_cpu+0x18/0x1d0 ? sched_clock_cpu+0x18/0x1d0 __vfs_write+0xf7/0x620 ? ucma_close_id+0x60/0x60 ? kernel_read+0x110/0x110 ? time_hardirqs_on+0x19/0x580 ? lock_acquire+0x18b/0x3a0 ? finish_task_switch+0xf3/0x5d0 ? _raw_spin_unlock_irq+0x29/0x40 ? _raw_spin_unlock_irq+0x29/0x40 ? finish_task_switch+0x1be/0x5d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? security_file_permission+0x172/0x1e0 vfs_write+0x192/0x460 ksys_write+0xc6/0x1a0 ? __ia32_sys_read+0xb0/0xb0 ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe ? do_syscall_64+0x1d/0x470 do_syscall_64+0x9e/0x470 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 3c86aa7 ("RDMA/cm: Add RDMA CM support for IBoE devices") Link: https://lore.kernel.org/r/20200318101741.47211-1-leon@kernel.org Signed-off-by: Avihai Horon <avihaih@mellanox.com> Reviewed-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] ret_from_fork_asm+0x1b/0x30 [ 137.182693] </TASK> [ 137.182693] Modules linked in: [ 137.538483] ---[ end trace 0000000000000000 ]--- Fixes: 1b05ece ("crypto: ccp - During shutdown, check SEV data pointer before using") Cc: stable@vger.kernel.org Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Acked-by: John Allen <john.allen@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Dave Hansen reports the following crash on a 32-bit system with CONFIG_HIGHMEM=y and CONFIG_X86_PAE=y: > 0xf75fe000 is the mem_map[] entry for the first page >4GB. It > obviously wasn't allocated, thus the oops. BUG: unable to handle page fault for address: f75fe000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pdpt = 0000000002da2001 *pde = 000000000300c067 *pte = 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc1-00288-ge618ee89561b-dirty thesofproject#311 PREEMPT(undef) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 EIP: __free_pages_core+0x3c/0x74 ... Call Trace: memblock_free_pages+0x11/0x2c memblock_free_all+0x2ce/0x3a0 mm_core_init+0xf5/0x320 start_kernel+0x296/0x79c i386_start_kernel+0xad/0xb0 startup_32_smp+0x151/0x154 The mem_map[] is allocated up to the end of ZONE_HIGHMEM which is defined by max_pfn. The bug was introduced by this recent commit: 6faea34 ("arch, mm: streamline HIGHMEM freeing") Previously, freeing of high memory was also clamped to the end of ZONE_HIGHMEM but after this change, memblock_free_all() tries to free memory above the of ZONE_HIGHMEM as well and that causes access to mem_map[] entries beyond the end of the memory map. To fix this, discard the memory after max_pfn from memblock on 32-bit systems so that core MM would be aware only of actually usable memory. Fixes: 6faea34 ("arch, mm: streamline HIGHMEM freeing") Reported-by: Dave Hansen <dave.hansen@intel.com> Tested-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Shevchenko <andy@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Davide Ciminaghi <ciminaghi@gnudd.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org Link: https://lore.kernel.org/r/20250413080858.743221-1-rppt@kernel.org # discussion and submission

…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 thesofproject#2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 thesofproject#2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 thesofproject#2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 thesofproject#2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 thesofproject#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 thesofproject#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 thesofproject#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 thesofproject#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 thesofproject#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 thesofproject#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

bardliao requested review from lgirdwood and plbossart November 23, 2018 08:17

bardliao mentioned this pull request Nov 23, 2018
Kernel panic after unloading and reloading driver #144
Closed

lgirdwood requested a review from keyonjie November 23, 2018 12:48

plbossart reviewed Nov 25, 2018
View reviewed changes

Comment threadsound/soc/sof/intel/hda-codec.c Outdated

keyonjie reviewed Nov 26, 2018
View reviewed changes

Comment threadsound/soc/sof/intel/hda-codec.c Outdated

bardliao force-pushed the rmmod branch from 344d774 to abcbf95Compare November 26, 2018 11:34

plbossart requested changes Nov 26, 2018
View reviewed changes

Comment threadsound/soc/sof/intel/hda.c Outdated
plbossartNov 26, 2018
Copy link
Copy Markdown
Member
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be the other way around, do this before hda_codec_i915_exit()

bardliao force-pushed the rmmod branch 3 times, most recently from 4d7a23e to 2b5e769Compare November 27, 2018 08:01

bardliao mentioned this pull request Nov 27, 2018
SOF_HDA: need to clean-up exit sequences #299
Closed

plbossart requested changes Nov 27, 2018
View reviewed changes

Comment threadsound/soc/sof/intel/hda.c Outdated

bardliao force-pushed the rmmod branch 2 times, most recently from a114192 to d9dfa9fCompare November 28, 2018 02:56

plbossart reviewed Nov 28, 2018
View reviewed changes

Comment threadsound/soc/sof/intel/hda.c Outdated

bardliao force-pushed the rmmod branch from d9dfa9f to b20e23dCompare November 28, 2018 12:54

plbossart approved these changes Nov 28, 2018
View reviewed changes

plbossart merged commit fa06c6d into thesofproject:topic/sof-devNov 28, 2018

Navigation Menu

Uh oh!

ASoC: SOF: Intel: add balanced code of snd_hdac_ext_bus_device_init - #311

ASoC: SOF: Intel: add balanced code of snd_hdac_ext_bus_device_init#311
plbossart merged 1 commit into
thesofproject:topic/sof-devfrom
bardliao:rmmod

bardliao commented Nov 23, 2018

Uh oh!

bardliao commented Nov 23, 2018

Uh oh!

lgirdwood commented Nov 23, 2018

Uh oh!

Uh oh!

keyonjie left a comment

Uh oh!

Uh oh!

plbossartNov 26, 2018

Uh oh!

plbossart left a comment

Uh oh!

Uh oh!

bardliao commented Nov 28, 2018

Uh oh!

Uh oh!

plbossart left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

bardliao commented Nov 23, 2018

Uh oh!

bardliao commented Nov 23, 2018

Uh oh!

lgirdwood commented Nov 23, 2018

Uh oh!

Uh oh!

keyonjie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

plbossartNov 26, 2018

Choose a reason for hiding this comment

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bardliao commented Nov 28, 2018

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants