- Dec 14, 2024
-
-
Zhang Changzhong authored
[ Upstream commit d256d612 ] Fix missing call to regmap_del_irq_chip() in error handling path by using devm_regmap_add_irq_chip(). Fixes: 0b271258 ("mfd: rt5033: Add Richtek RT5033 driver core.") Signed-off-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1730302867-8391-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kashyap Desai authored
[ Upstream commit 808ca6de ] Invalidate rkey is cpu endian and immediate data is in big endian format. Both immediate data and invalidate the remote key returned by HW is in little endian format. While handling the commit in fixes tag, the difference between immediate data and invalidate rkey endianness was not considered. Without changes of this patch, Kernel ULP was failing while processing inv_rkey. dmesg log snippet - nvme nvme0: Bogus remote invalidation for rkey 0x2000019Fix in this patch Do endianness conversion based on completion queue entry flag. Also, the HW completions are already converted to host endianness in bnxt_qplib_cq_process_res_rc and bnxt_qplib_cq_process_res_ud and there is no need to convert it again in bnxt_re_poll_cq. Modified the union to hold the correct data type. Fixes: 95b087f8 ("bnxt_re: Fix imm_data endianness") Signed-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1730110014-20755-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Michael Ellerman authored
[ Upstream commit cadae3a4 ] The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258 Fixes: 06220d78 ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage") Tested-by:
Kajol Jain <kjain@linux.ibm.com> Reviewed-by:
Nysal Jan K.A <nysal@linux.ibm.com> Reviewed-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20240819122401.513203-1-mpe@ellerman.id.au Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Miquel Raynal authored
[ Upstream commit 6d734f1b ] The pmecc "user" structure is allocated in atmel_pmecc_create_user() and was supposed to be freed with atmel_pmecc_destroy_user(), but this other helper is never called. One solution would be to find the proper location to call the destructor, but the trend today is to switch to device managed allocations, which in this case fits pretty well. Replace kzalloc() by devm_kzalloc() and drop the destructor entirely. Reported-by:
"Dr. David Alan Gilbert" <linux@treblig.org> Closes: https://lore.kernel.org/all/ZvmIvRJCf6VhHvpo@gallifrey/ Fixes: f88fc122 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20241001203149.387655-1-miquel.raynal@bootlin.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yuan Can authored
[ Upstream commit 5f856d71 ] When cpufreq_register_driver() returns error, the cpufreq_init() returns without unregister platform_driver, fix by add missing platform_driver_unregister() when cpufreq_register_driver() failed. Fixes: f8ede0f7 ("MIPS: Loongson 2F: Add CPU frequency scaling support") Signed-off-by:
Yuan Can <yuancan@huawei.com> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit 0350d783 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 57129044 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Tested-by:
Zhang Ning <zhangn1985@outlook.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241005193029.1929139-4-andriy.shevchenko@linux.intel.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit 9b79d59e ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 957ae509 ("platform/x86: Add Whiskey Cove PMIC TMU support") Fixes: 57129044 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by:
Zhang Ning <zhangn1985@outlook.com> Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by:
Zhang Ning <zhangn1985@outlook.com> Acked-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241005193029.1929139-3-andriy.shevchenko@linux.intel.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit 686fb777 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 9c6235c8 ("mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device") Fixes: d2061f9c ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY") Fixes: 57129044 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by:
Zhang Ning <zhangn1985@outlook.com> Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by:
Zhang Ning <zhangn1985@outlook.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20241005193029.1929139-2-andriy.shevchenko@linux.intel.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit d30e2c30 ] Simplify the mux error path a bit by using dev_err_probe(). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220628221747.33956-4-andriy.shevchenko@linux.intel.com Stable-dep-of: 686fb777 ("mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marcus Folkesson authored
[ Upstream commit 2e3378f6 ] Driver has mixed up the R/W bit. The LSB bit is set on write rather than read. Change it to avoid nasty things to happen. Fixes: e9e9d397 ("mfd: da9052: Avoid setting read_flag_mask for da9052-i2c driver") Signed-off-by:
Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20240925-da9052-v2-1-f243e4505b07@gmail.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jinjie Ruan authored
[ Upstream commit 2174f9a8 ] As the comment said, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 72cd7995 ("[PATCH] I2C: add i2c driver for TPS6501x") Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20240912031530.2211654-1-ruanjinjie@huawei.com Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christophe Leroy authored
[ Upstream commit 0161bd38 ] On powerpc64 as shown below by readelf, vDSO functions symbols have type NOTYPE. $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg ELF Header: Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: PowerPC64 Version: 0x1 ... Symbol table '.dynsym' contains 12 entries: Num: Value Size Type Bind Vis Ndx Name ... 1: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 ... 4: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 5: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 Symbol table '.symtab' contains 56 entries: Num: Value Size Type Bind Vis Ndx Name ... 45: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 46: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __kernel_getcpu 47: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __kernel_clock_getres To overcome that, commit ba83b323 ("selftests: vDSO: fix vDSO symbols lookup for powerpc64") was applied to have selftests also look for NOTYPE symbols, but the correct fix should be to flag VDSO entry points as functions. The original commit that brought VDSO support into powerpc/64 has the following explanation: Note that the symbols exposed by the vDSO aren't "normal" function symbols, apps can't be expected to link against them directly, the vDSO's are both seen as if they were linked at 0 and the symbols just contain offsets to the various functions. This is done on purpose to avoid a relocation step (ppc64 functions normally have descriptors with abs addresses in them). When glibc uses those functions, it's expected to use it's own trampolines that know how to reach them. The descriptors it's talking about are the OPD function descriptors used on ABI v1 (big endian). But it would be more correct for a text symbol to have type function, even if there's no function descriptor for it. glibc has a special case already for handling the VDSO symbols which creates a fake opd pointing at the kernel symbol. So changing the VDSO symbol type to function shouldn't affect that. For ABI v2, there is no function descriptors and VDSO functions can safely have function type. So lets flag VDSO entry points as functions and revert the selftest change. Link: https://github.com/mpe/linux-fullhistory/commit/5f2dd691b62da9d9cc54b938f8b29c22c93cb805 Fixes: ba83b323 ("selftests: vDSO: fix vDSO symbols lookup for powerpc64") Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-By:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/b6ad2f1ee9887af3ca5ecade2a56f4acda517a85.1728512263.git.christophe.leroy@csgroup.eu Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Levi Yun authored
[ Upstream commit afe5960d ] When a tracepoint event is created with attr.freq = 1, 'hwc->period_left' is not initialized correctly. As a result, in the perf_swevent_overflow() function, when the first time the event occurs, it calculates the event overflow and the perf_swevent_set_period() returns 3, this leads to the event are recorded for three duplicate times. Step to reproduce: 1. Enable the tracepoint event & starting tracing $ echo 1 > /sys/kernel/tracing/events/module/module_free $ echo 1 > /sys/kernel/tracing/tracing_on 2. Record with perf $ perf record -a --strict-freq -F 1 -e "module:module_free" 3. Trigger module_free event. $ modprobe -i sunrpc $ modprobe -r sunrpc Result: - Trace pipe result: $ cat trace_pipe modprobe-174509 [003] ..... 6504.868896: module_free: sunrpc - perf sample: modprobe 174509 [003] 6504.868980: module:module_free: sunrpc modprobe 174509 [003] 6504.868980: module:module_free: sunrpc modprobe 174509 [003] 6504.868980: module:module_free: sunrpc By setting period_left via perf_swevent_set_period() as other sw_event did, This problem could be solved. After patch: - Trace pipe result: $ cat trace_pipe modprobe 1153096 [068] 613468.867774: module:module_free: xfs - perf sample modprobe 1153096 [068] 613468.867794: module:module_free: xfs Link: https://lore.kernel.org/20240913021347.595330-1-yeoreum.yun@arm.com Fixes: bd2b5b12 ("perf_counter: More aggressive frequency adjustment") Signed-off-by:
Levi Yun <yeoreum.yun@arm.com> Acked-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hangbin Liu authored
[ Upstream commit 0290abc9 ] Some distros may not load nf_conntrack by default, which will cause subsequent nf_conntrack sets to fail. Load this module if it is not already loaded. Fixes: e7096c13 ("net: WireGuard secure network tunnel") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Simon Horman <horms@kernel.org> [ Jason: add [[ -e ... ]] check so this works in the qemu harness. ] Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20241117212030.629159-4-Jason@zx2c4.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Breno Leitao authored
[ Upstream commit a57d5a72 ] The ndev->npinfo pointer in netpoll_poll_lock() is RCU-protected but is being accessed directly for a NULL check. While no RCU read lock is held in this context, we should still use proper RCU primitives for consistency and correctness. Replace the direct NULL check with rcu_access_pointer(), which is the appropriate primitive when only checking for NULL without dereferencing the pointer. This function provides the necessary ordering guarantees without requiring RCU read-side protection. Fixes: bea3348e ("[NET]: Make NAPI polling independent of struct net_device objects.") Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/20241118-netpoll_rcu-v1-2-a1888dcb4a02@debian.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dmitry Antipov authored
[ Upstream commit 27aabf27 ] Syzbot has reported the following KASAN splat: BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ? __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0 kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ? __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ? __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ? __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250 do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210 arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly. Reported-by:
<syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com> Tested-by:
<syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=6cf5652d3df49fae2e3f Fixes: a85fb91e ("Bluetooth: Fix double free in hci_conn_cleanup") Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andy Shevchenko authored
[ Upstream commit 82b070be ] There are several places in the kernel where this kind of functionality is being used. Provide a generic helper for such cases. Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20220610120219.18988-1-andriy.shevchenko@linux.intel.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 27aabf27 ("Bluetooth: fix use-after-free in device_for_each_child()") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit a0810c3d ] The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. Fixes: c6d43ba8 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-6-tiwai@suse.de Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit b04dcbb7 ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor. Fixes: 523f1dce ("[ALSA] Add Native Instrument usb audio device support") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-5-tiwai@suse.de Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit b7df09bb ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed(). Fixes: 030a07e4 ("ALSA: Add USB US122L driver") Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-3-tiwai@suse.de Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit dafb28f0 ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. Fixes: 230cd5e2 ("[ALSA] prevent oops & dead keyboard on usb unplugging while the device is be ing used") Reported-by:
<syzbot+73582d08864d8268b6fd@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=73582d08864d8268b6fd Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-2-tiwai@suse.de Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit 2ac7a12e ] Minor code refactoring by merging the superfluous function calls. The functions were split in the past for covering pre-history USB driver code, but this is utterly useless. Link: https://lore.kernel.org/r/20210517131545.27252-11-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: dafb28f0 ("ALSA: usx2y: Use snd_card_free_when_closed() at disconnection") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit a829dd5b ] This patch fixes various trivial coding-style issues in usx2y code, such as: * the assginments in if condition * comparison order with constants * NULL / zero checks * unsigned -> unsigned int * addition of braces in control blocks * debug print with function names * move local variables in block into function head * reduction of too nested indentations No functional changes. Link: https://lore.kernel.org/r/20210517131545.27252-4-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: dafb28f0 ("ALSA: usx2y: Use snd_card_free_when_closed() at disconnection") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Takashi Iwai authored
[ Upstream commit 4c0a58ef ] This patch corrects merely the spaces in the usx2y code, including the superfluous trailing space in the debug prints and a slight reformat of some comment lines. Nothing really touches about the code itself. Link: https://lore.kernel.org/r/20210517131545.27252-3-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: dafb28f0 ("ALSA: usx2y: Use snd_card_free_when_closed() at disconnection") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mingwei Zheng authored
[ Upstream commit 8251e762 ] Add check for the return value of clk_enable() to catch the potential error. Fixes: 7176ba23 ("net: rfkill: add generic gpio rfkill driver") Signed-off-by:
Mingwei Zheng <zmw12306@gmail.com> Signed-off-by:
Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://patch.msgid.link/20241108195341.1853080-1-zmw12306@gmail.com Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yuan Can authored
[ Upstream commit 21cae8de ] In kfd_procfs_show(), the sdma_activity_work_handler is a local variable and the sdma_activity_work_handler.sdma_activity_work should initialize with INIT_WORK_ONSTACK() instead of INIT_WORK(). Fixes: 32cb59f3 ("drm/amdkfd: Track SDMA utilization per process") Signed-off-by:
Yuan Can <yuancan@huawei.com> Signed-off-by:
Felix Kuehling <felix.kuehling@amd.com> Reviewed-by:
Felix Kuehling <felix.kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Paolo Abeni authored
[ Upstream commit 52ed077a ] A recent refactor transformed the check for process completion in a true statement, due to a typo. As a result, the relevant test-case is unable to catch the regression it was supposed to detect. Restore the correct condition. Fixes: 691bb4e4 ("selftests: net: avoid just another constant wait") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/0e6f213811f8e93a235307e683af8225cc6277ae.1730828007.git.pabeni@redhat.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 955afd57 ] Found in the test_txmsg_pull in test_sockmap, ``` txmsg_cork = 512; // corking is importrant here opt->iov_length = 3; opt->iov_count = 1; opt->rate = 512; // sendmsg will be invoked 512 times ``` The first sendmsg will send an sk_msg with size 3, and bpf_msg_pull_data will be invoked the first time. sk_msg_reset_curr will reset the copybreak from 3 to 0. In the second sendmsg, since we are in the stage of corking, psock->cork will be reused in func sk_msg_alloc. msg->sg.copybreak is 0 now, the second msg will overwrite the first msg. As a result, we could not pass the data integrity test. The same problem happens in push and pop test. Thus, fix sk_msg_reset_curr to restore the correct copybreak. Fixes: bb9aefde ("bpf: sockmap, updating the sg structure should also update curr") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241106222520.527076-9-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 5d609ba2 ] Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. Fixes: 7246d8ed ("bpf: helper to pop data from messages") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-8-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 15ab0548 ] Several fixes to bpf_msg_push_data, 1. test_sockmap has tests where bpf_msg_push_data is invoked to push some data at the end of a message, but -EINVAL is returned. In this case, in bpf_msg_push_data, after the first loop, i will be set to msg->sg.end, add the logic to handle it. 2. In the code block of "if (start - offset)", it's possible that "i" points to the last of sk_msg_elem. In this case, "sk_msg_iter_next(msg, end)" might still be called twice, another invoking is in "if (!copy)" code block, but actually only one is needed. Add the logic to handle it, and reconstruct the code to make the logic more clear. Fixes: 6fff607e ("bpf: sk_msg program helper bpf_msg_push_data") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241106222520.527076-7-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 862087c3 ] Add push/pop checking for msg_verify_data in test_sockmap, except for pop/push with cork tests, in these tests the logic will be different. 1. With corking, pop/push might not be invoked in each sendmsg, it makes the layout of the received data difficult 2. It makes it hard to calculate the total_bytes in the recvmsg Temporarily skip the data integrity test for these cases now, added a TODO Fixes: ee9b352c ("selftests/bpf: Fix msg_verify_data in test_sockmap") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-5-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 523dffcc ] total_bytes in msg_loop_rx should also take push into account, otherwise total_bytes will be a smaller value, which makes the msg_loop_rx end early. Besides, total_bytes has already taken pop into account, so we don't need to subtract some bytes from iov_buf in sendmsg_test. The additional subtraction may make total_bytes a negative number, and msg_loop_rx will just end without checking anything. Fixes: 18d4e900 ("bpf: Selftests, improve test_sockmap total bytes counter") Fixes: d6967214 ("selftests, bpf: Add one test for sockmap with strparser") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-4-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Liu Jian authored
[ Upstream commit d6967214 ] Add the test to check sockmap with strparser is working well. Signed-off-by:
Liu Jian <liujian56@huawei.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20211029141216.211899-3-liujian56@huawei.com Stable-dep-of: 523dffcc ("selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 40950314 ] In the SENDPAGE test, "opt->iov_length * cnt" size of data will be sent cnt times by sendfile. 1. In push/pop tests, they will be invoked cnt times, for the simplicity of msg_verify_data, change chunk_sz to iov_length 2. Change iov_length in test_send_large from 1024 to 8192. We have pop test where txmsg_start_pop is 4096. 4096 > 1024, an error will be returned. Fixes: 328aa08a ("bpf: Selftests, break down test_sockmap into subtests") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-3-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zijian Zhang authored
[ Upstream commit 66c54c20 ] Add txmsg_pass to test_txmsg_pull/push/pop. If txmsg_pass is missing, tx_prog will be NULL, and no program will be attached to the sockmap. As a result, pull/push/pop are never invoked. Fixes: 328aa08a ("bpf: Selftests, break down test_sockmap into subtests") Signed-off-by:
Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-2-zijianzhang@bytedance.com Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Maurice Lambert authored
[ Upstream commit 84bfbfbb ] This commit fix a typographical error in netlink nlmsg_type constants definition in the include/uapi/linux/rtnetlink.h at line 177. The definition is RTM_NEWNVLAN RTM_NEWVLAN instead of RTM_NEWVLAN RTM_NEWVLAN. Signed-off-by:
Maurice Lambert <mauricelambert434@gmail.com> Fixes: 8dcea187 ("net: bridge: vlan: add rtm definitions and dump support") Link: https://patch.msgid.link/20241103223950.230300-1-mauricelambert434@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Zichen Xie authored
[ Upstream commit 20c7b42d ] There may be a potential integer overflow issue in _dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while mode->vtotal, mode->hdisplay, and drm_mode_vrefresh(mode) are defined as a smaller data type. The result of the calculation will be limited to "int" in this case without correct casting. In screen with high resolution and high refresh rate, integer overflow may happen. So, we recommend adding an extra cast to prevent potential integer overflow. Fixes: c33b7c03 ("drm/msm/dpu: add support for clk and bw scaling for display") Signed-off-by:
Zichen Xie <zichenxie0106@gmail.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/622206/ Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yuan Can authored
[ Upstream commit 3b88a987 ] The wfx_core_init() returns without checking the retval from sdio_register_driver(). If the sdio_register_driver() failed, the module failed to install, leaving the wfx_spi_driver not unregistered. Fixes: a7a91ca5 ("staging: wfx: add infrastructure for new driver") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lucas Stach authored
[ Upstream commit 37dc4737 ] The perfmon sampling mutates shared GPU state (e.g. VIVS_HI_CLOCK_CONTROL to select the pipe for the perf counter reads). To avoid clashing with other functions mutating the same state (e.g. etnaviv_gpu_update_clock) the perfmon sampling needs to hold the GPU lock. Fixes: 68dc0b29 ("drm/etnaviv: use 'sync points' for performance monitor requests") Reviewed-by:
Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Doug Brown authored
[ Upstream commit 61a6920b ] Older GC300 revisions have their power registers at an offset of 0x200 rather than 0x100. Add new gpu_read_power and gpu_write_power functions to encapsulate accesses to the power addresses and fix the addresses. Signed-off-by:
Doug Brown <doug@schmorgal.com> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Stable-dep-of: 37dc4737 ("drm/etnaviv: hold GPU lock across perfmon sampling") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-