Author: bo liu <[email protected]> Date: Fri Nov 29 09:44:41 2024 +0800 ALSA: hda/conexant: fix Z60MR100 startup pop issue [ Upstream commit 947c4012f8f03a8bb946beb6e5294d5e32817d67 ] When Z60MR100 startup, speaker will output a pop. To fix this issue, we mute codec by init verbs in bios when system startup, and set GPIO to low to unmute codec in codec driver when it loaded . [ white space fixes and compile warning fix by tiwai ] Signed-off-by: bo liu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Chiu <[email protected]> Date: Mon Dec 2 22:46:59 2024 +0800 ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops [ Upstream commit 0d08f0eec961acdb0424a3e2cfb37cfb89154833 ] These HP laptops use Realtek HDA codec ALC3315 combined CS35L56 Amplifiers. They need the quirk ALC285_FIXUP_HP_GPIO_LED to get the micmute LED working. Signed-off-by: Chris Chiu <[email protected]> Reviewed-by: Simon Trimmer <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dirk Su <[email protected]> Date: Tue Nov 26 14:05:24 2024 +0800 ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook X G1i [ Upstream commit 7ba81e4c3aa0ca25f06dc4456e7d36fa8e76385f ] HP EliteBook X G1i needs ALC285_FIXUP_HP_GPIO_LED quirk to make mic-mute/audio-mute working. Signed-off-by: Dirk Su <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Stable-dep-of: 0d08f0eec961 ("ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops") Signed-off-by: Sasha Levin <[email protected]>
Author: Colin Ian King <[email protected]> Date: Thu Dec 5 10:28:33 2024 +0000 ALSA: hda/realtek: Fix spelling mistake "Firelfy" -> "Firefly" commit 20c3b3e5f2641eff3d85f33e6a468ac052b169bd upstream. There is a spelling mistake in a literal string in the alc269_fixup_tbl quirk table. Fix it. Fixes: 0d08f0eec961 ("ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops") Signed-off-by: Colin Ian King <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Fri Dec 20 12:44:16 2024 +0100 ALSA: sh: Fix wrong argument order for copy_from_iter() commit 66a0a2b0473c39ae85c44628d14e4366fdc0aa0d upstream. Fix a brown paper bag bug I introduced at converting to the standard iter helper; the arguments were wrongly passed and have to be swapped. Fixes: 9b5f8ee43e48 ("ALSA: sh: Use standard helper for buffer accesses") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Thu Nov 28 11:49:38 2024 +0100 ALSA: sh: Use standard helper for buffer accesses [ Upstream commit 9b5f8ee43e48c25fbe1a10163ec04343d750acd0 ] The SH DAC audio driver uses the kmalloc'ed buffer as the main PCM buffer, and the data is transferred via hrtimer callbacks manually from there to the hardware. Meanwhile, some of its code are written as if the buffer is on iomem and use the special helpers for the iomem (e.g. copy_from_iter_toio() or memset_io()). Those are rather useless and the standard helpers should be used. Similarly, the PCM mmap callback is set to a special one with snd_pcm_lib_mmap_iomem, but this is also nonsense, because SH architecture doesn't support this function, hence it leads just to NULL -- the fallback to the standard helper. This patch replaces those special setups with the standard ones. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Fri Dec 6 19:16:07 2024 +0800 blk-mq: move cpuhp callback registering out of q->sysfs_lock [ Upstream commit 22465bbac53c821319089016f268a2437de9b00a ] Registering and unregistering cpuhp callback requires global cpu hotplug lock, which is used everywhere. Meantime q->sysfs_lock is used in block layer almost everywhere. It is easy to trigger lockdep warning[1] by connecting the two locks. Fix the warning by moving blk-mq's cpuhp callback registering out of q->sysfs_lock. Add one dedicated global lock for covering registering & unregistering hctx's cpuhp, and it is safe to do so because hctx is guaranteed to be live if our request_queue is live. [1] https://lore.kernel.org/lkml/Z04pz3AlvI4o0Mr8@agluck-desk3/ Cc: Reinette Chatre <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: Peter Newman <[email protected]> Cc: Babu Moger <[email protected]> Reported-by: Luck Tony <[email protected]> Signed-off-by: Ming Lei <[email protected]> Tested-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Fri Dec 6 19:16:06 2024 +0800 blk-mq: register cpuhp callback after hctx is added to xarray table [ Upstream commit 4bf485a7db5d82ddd0f3ad2b299893199090375e ] We need to retrieve 'hctx' from xarray table in the cpuhp callback, so the callback should be registered after this 'hctx' is added to xarray table. Cc: Reinette Chatre <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: Peter Newman <[email protected]> Cc: Babu Moger <[email protected]> Cc: Luck Tony <[email protected]> Signed-off-by: Ming Lei <[email protected]> Tested-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Wed Dec 18 18:16:15 2024 +0800 block: avoid to reuse `hctx` not removed from cpuhp callback list commit 85672ca9ceeaa1dcf2777a7048af5f4aee3fd02b upstream. If the 'hctx' isn't removed from cpuhp callback list, we can't reuse it, otherwise use-after-free may be triggered. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-lkp/[email protected] Tested-by: kernel test robot <[email protected]> Fixes: 22465bbac53c ("blk-mq: move cpuhp callback registering out of q->sysfs_lock") Signed-off-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cong Wang <[email protected]> Date: Thu Dec 12 19:40:54 2024 -0800 bpf: Check negative offsets in __bpf_skb_min_len() [ Upstream commit 9ecc4d858b92c1bb0673ad9c327298e600c55659 ] skb_network_offset() and skb_transport_offset() can be negative when they are called after we pull the transport header, for example, when we use eBPF sockmap at the point of ->sk_data_ready(). __bpf_skb_min_len() uses an unsigned int to get these offsets, this leads to a very large number which then causes bpf_skb_change_tail() failed unexpectedly. Fix this by using a signed int to get these offsets and ensure the minimum is at least zero. Fixes: 5293efe62df8 ("bpf: add bpf_skb_change_tail helper") Signed-off-by: Cong Wang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Mon Dec 9 16:43:44 2024 +0000 btrfs: avoid monopolizing a core when activating a swap file commit 2c8507c63f5498d4ee4af404a8e44ceae4345056 upstream. During swap activation we iterate over the extents of a file and we can have many thousands of them, so we can end up in a busy loop monopolizing a core. Avoid this by doing a voluntary reschedule after processing each extent. CC: [email protected] # 5.4+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Wed Dec 18 17:00:56 2024 +1030 btrfs: sysfs: fix direct super block member reads commit fca432e73db2bec0fdbfbf6d98d3ebcd5388a977 upstream. The following sysfs entries are reading super block member directly, which can have a different endian and cause wrong values: - sys/fs/btrfs/<uuid>/nodesize - sys/fs/btrfs/<uuid>/sectorsize - sys/fs/btrfs/<uuid>/clone_alignment Thankfully those values (nodesize and sectorsize) are always aligned inside the btrfs_super_block, so it won't trigger unaligned read errors, just endian problems. Fix them by using the native cached members instead. Fixes: df93589a1737 ("btrfs: export more from FS_INFO to sysfs") CC: [email protected] Reviewed-by: Naohiro Aota <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ilya Dryomov <[email protected]> Date: Sat Dec 7 17:33:25 2024 +0100 ceph: allocate sparse_ext map only for sparse reads [ Upstream commit 18d44c5d062b97b97bb0162d9742440518958dc1 ] If mounted with sparseread option, ceph_direct_read_write() ends up making an unnecessarily allocation for O_DIRECT writes. Fixes: 03bc06c7b0bd ("ceph: add new mount option to enable sparse reads") Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilya Dryomov <[email protected]> Date: Fri Dec 6 17:32:59 2024 +0100 ceph: fix memory leak in ceph_direct_read_write() [ Upstream commit 66e0c4f91461d17d48071695271c824620bed4ef ] The bvecs array which is allocated in iter_get_bvecs_alloc() is leaked and pages remain pinned if ceph_alloc_sparse_ext_map() fails. There is no need to delay the allocation of sparse_ext map until after the bvecs array is set up, so fix this by moving sparse_ext allocation a bit earlier. Also, make a similar adjustment in __ceph_sync_read() for consistency (a leak of the same kind in __ceph_sync_read() has been addressed differently). Cc: [email protected] Fixes: 03bc06c7b0bd ("ceph: add new mount option to enable sparse reads") Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Alex Markuze <[email protected]> Stable-dep-of: 18d44c5d062b ("ceph: allocate sparse_ext map only for sparse reads") Signed-off-by: Sasha Levin <[email protected]>
Author: Xiubo Li <[email protected]> Date: Tue Nov 7 10:44:41 2023 +0800 ceph: try to allocate a smaller extent map for sparse read [ Upstream commit aaefabc4a5f7ae48682c4d2d5d10faaf95c08eb9 ] In fscrypt case and for a smaller read length we can predict the max count of the extent map. And for small read length use cases this could save some memories. [ idryomov: squash into a single patch to avoid build break, drop redundant variable in ceph_alloc_sparse_ext_map() ] Signed-off-by: Xiubo Li <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]> Stable-dep-of: 18d44c5d062b ("ceph: allocate sparse_ext map only for sparse reads") Signed-off-by: Sasha Levin <[email protected]>
Author: Sasha Finkelstein <[email protected]> Date: Sun Nov 24 16:48:28 2024 +0100 dmaengine: apple-admac: Avoid accessing registers in probe commit 8d55e8a16f019211163f1180fd9f9fbe05901900 upstream. The ADMAC attached to the AOP has complex power sequencing, and is power gated when the probe callback runs. Move the register reads to other functions, where we can guarantee that the hardware is switched on. Fixes: 568aa6dd641f ("dmaengine: apple-admac: Allocate cache SRAM to channels") Signed-off-by: Sasha Finkelstein <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Ridong <[email protected]> Date: Tue Oct 29 08:28:45 2024 +0000 dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset commit c43ec96e8d34399bd9dab2f2dc316b904892133f upstream. The at_xdmac_memset_create_desc may return NULL, which will lead to a null pointer dereference. For example, the len input is error, or the atchan->free_descs_list is empty and memory is exhausted. Therefore, add check to avoid this. Fixes: b206d9a23ac7 ("dmaengine: xdmac: Add memset support") Signed-off-by: Chen Ridong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Mon Nov 4 11:50:50 2024 +0200 dmaengine: dw: Select only supported masters for ACPI devices commit f0e870a0e9c5521f2952ea9f3ea9d3d122631a89 upstream. The recently submitted fix-commit revealed a problem in the iDMA 32-bit platform code. Even though the controller supported only a single master the dw_dma_acpi_filter() method hard-coded two master interfaces with IDs 0 and 1. As a result the sanity check implemented in the commit b336268dde75 ("dmaengine: dw: Add peripheral bus width verification") got incorrect interface data width and thus prevented the client drivers from configuring the DMA-channel with the EINVAL error returned. E.g., the next error was printed for the PXA2xx SPI controller driver trying to configure the requested channels: > [ 164.525604] pxa2xx_spi_pci 0000:00:07.1: DMA slave config failed > [ 164.536105] pxa2xx_spi_pci 0000:00:07.1: failed to get DMA TX descriptor > [ 164.543213] spidev spi-SPT0001:00: SPI transfer failed: -16 The problem would have been spotted much earlier if the iDMA 32-bit controller supported more than one master interfaces. But since it supports just a single master and the iDMA 32-bit specific code just ignores the master IDs in the CTLLO preparation method, the issue has been gone unnoticed so far. Fix the problem by specifying the default master ID for both memory and peripheral devices in the driver data. Thus the issue noticed for the iDMA 32-bit controllers will be eliminated and the ACPI-probed DW DMA controllers will be configured with the correct master ID by default. Cc: [email protected] Fixes: b336268dde75 ("dmaengine: dw: Add peripheral bus width verification") Fixes: 199244d69458 ("dmaengine: dw: add support of iDMA 32-bit hardware") Reported-by: Ferry Toth <[email protected]> Closes: https://lore.kernel.org/dmaengine/[email protected]/ Reported-by: Andy Shevchenko <[email protected]> Closes: https://lore.kernel.org/dmaengine/[email protected]/ Tested-by: Ferry Toth <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joe Hattori <[email protected]> Date: Sat Dec 21 16:57:12 2024 +0900 dmaengine: fsl-edma: implement the cleanup path of fsl_edma3_attach_pd() commit ccfa3131d4a0347988e73638edea5c8281b6d2c7 upstream. Current implementation of fsl_edma3_attach_pd() does not provide a cleanup path, resulting in a memory leak. For example, dev_pm_domain_detach() is not called after dev_pm_domain_attach_by_id(), and the device link created with the DL_FLAG_STATELESS is not released explicitly. Therefore, provide a cleanup function fsl_edma3_detach_pd() and call it upon failure. Also add a devm_add_action_or_reset() call with this function after a successful fsl_edma3_attach_pd(). Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Joe Hattori <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Javier Carrasco <[email protected]> Date: Fri Oct 11 22:57:59 2024 +0200 dmaengine: mv_xor: fix child node refcount handling in early exit commit 362f1bf98a3ecb5a2a4fcbdaa9718c8403beceb2 upstream. The for_each_child_of_node() loop requires explicit calls to of_node_put() to decrement the child's refcount upon early exits (break, goto, return). Add the missing calls in the two early exits before the goto instructions. Cc: [email protected] Fixes: f7d12ef53ddf ("dma: mv_xor: add Device Tree binding") Signed-off-by: Javier Carrasco <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Akhil R <[email protected]> Date: Thu Dec 12 18:14:12 2024 +0530 dmaengine: tegra: Return correct DMA status when paused commit ebc008699fd95701c9af5ebaeb0793eef81a71d5 upstream. Currently, the driver does not return the correct DMA status when a DMA pause is issued by the client drivers. This causes GPCDMA users to assume that DMA is still running, while in reality, the DMA is paused. Return DMA_PAUSED for tx_status() if the channel is paused in the middle of a transfer. Fixes: ee17028009d4 ("dmaengine: tegra: Add tegra gpcdma driver") Cc: [email protected] Signed-off-by: Akhil R <[email protected]> Signed-off-by: Kartik Rajput <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Victor Zhao <[email protected]> Date: Mon Aug 19 11:16:13 2024 +0800 drm/amd/amdgpu: allow use kiq to do hdp flush under sriov [ Upstream commit bf2bc61638033d118c9ef4ab1204295ba6694401 ] when use cpu to do page table update under sriov runtime, since mmio access is blocked, kiq has to be used to flush hdp. change WREG32_NO_KIQ to WREG32 to allow kiq. Signed-off-by: Victor Zhao <[email protected]> Reviewed-by: Emily Deng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: c9b8dcabb52a ("drm/amdgpu/hdp4.0: do a posting read when flushing HDP") Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Nov 22 11:22:51 2024 -0500 drm/amdgpu/hdp4.0: do a posting read when flushing HDP [ Upstream commit c9b8dcabb52afe88413ff135a0953e3cc4128483 ] Need to read back to make sure the write goes through. Cc: David Belanger <[email protected]> Reviewed-by: Frank Min <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Nov 22 11:23:56 2024 -0500 drm/amdgpu/hdp5.0: do a posting read when flushing HDP [ Upstream commit cf424020e040be35df05b682b546b255e74a420f ] Need to read back to make sure the write goes through. Cc: David Belanger <[email protected]> Reviewed-by: Frank Min <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Fri Nov 22 11:24:38 2024 -0500 drm/amdgpu/hdp6.0: do a posting read when flushing HDP [ Upstream commit abe1cbaec6cfe9fde609a15cd6a12c812282ce77 ] Need to read back to make sure the write goes through. Cc: David Belanger <[email protected]> Reviewed-by: Frank Min <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Tue Sep 26 12:00:23 2023 -0400 drm/amdkfd: drop struct kfd_cu_info [ Upstream commit 0021d70a0654e668d457758110abec33dfbd3ba5 ] I think this was an abstraction back from when kfd supported both radeon and amdgpu. Since we just support amdgpu now, there is no more need for this and we can use the amdgpu structures directly. This also avoids having the kfd_cu_info structures on the stack when inlining which can blow up the stack. Cc: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd") Signed-off-by: Sasha Levin <[email protected]>
Author: [email protected] <[email protected]> Date: Thu Dec 5 17:41:26 2024 +0800 drm/amdkfd: pause autosuspend when creating pdd [ Upstream commit 438b39ac74e2a9dc0a5c9d653b7d8066877e86b1 ] When using MES creating a pdd will require talking to the GPU to setup the relevant context. The code here forgot to wake up the GPU in case it was in suspend, this causes KVM to EFAULT for passthrough GPU for example. This issue can be masked if the GPU was woken up by other things (e.g. opening the KMS node) first and have not yet gone to sleep. v4: do the allocation of proc_ctx_bo in a lazy fashion when the first queue is created in a process (Felix) Signed-off-by: Jesse Zhang <[email protected]> Reviewed-by: Yunxiang Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Thu Sep 21 10:32:09 2023 -0400 drm/amdkfd: reduce stack size in kfd_topology_add_device() [ Upstream commit 4ff91f218547bfc3d230c00e46725b71a625acbc ] kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger than 1024 bytes Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866 Cc: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd") Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Mon Jun 24 13:33:16 2024 +0530 drm/amdkfd: Use device based logging for errors [ Upstream commit 62ec7d38b769ccf33b1080e69c2ae5b7344d116d ] Convert some pr_* to some dev_* APIs to identify the device. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Stable-dep-of: 438b39ac74e2 ("drm/amdkfd: pause autosuspend when creating pdd") Signed-off-by: Sasha Levin <[email protected]>
Author: Imre Deak <[email protected]> Date: Wed Dec 4 15:20:07 2024 +0200 drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() [ Upstream commit e54b00086f7473dbda1a7d6fc47720ced157c6a8 ] While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req(). Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used. v2: Fix kfreeing the request if getting an mst_primary reference fails. Cc: Lyude Paul <[email protected]> Reviewed-by: Lyude Paul <[email protected]> (v1) Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Tue Dec 17 00:48:18 2024 +0000 freezer, sched: Report frozen tasks as 'D' instead of 'R' [ Upstream commit f718faf3940e95d5d34af9041f279f598396ab7d ] Before commit: f5d39b020809 ("freezer,sched: Rewrite core freezer logic") the frozen task stat was reported as 'D' in cgroup v1. However, after rewriting the core freezer logic, the frozen task stat is reported as 'R'. This is confusing, especially when a task with stat of 'S' is frozen. This bug can be reproduced with these steps: $ cd /sys/fs/cgroup/freezer/ $ mkdir test $ sleep 1000 & [1] 739 // task whose stat is 'S' $ echo 739 > test/cgroup.procs $ echo FROZEN > test/freezer.state $ ps -aux | grep 739 root 739 0.1 0.0 8376 1812 pts/0 R 10:56 0:00 sleep 1000 As shown above, a task whose stat is 'S' was changed to 'R' when it was frozen. To solve this regression, simply maintain the same reported state as before the rewrite. [ mingo: Enhanced the changelog and comments ] Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic") Signed-off-by: Chen Ridong <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Tejun Heo <[email protected]> Acked-by: Michal Koutný <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Song <[email protected]> Date: Wed Dec 18 12:42:38 2024 +0800 i2c: imx: add imx7d compatible string for applying erratum ERR007805 commit e0cec363197e41af870613e8e17b30bf0e3d41b5 upstream. Compatible string "fsl,imx7d-i2c" is not exited at i2c-imx driver compatible string table, at the result, "fsl,imx21-i2c" will be matched, but it will cause erratum ERR007805 not be applied in fact. So Add "fsl,imx7d-i2c" compatible string in i2c-imx driver to apply the erratum ERR007805(https://www.nxp.com/docs/en/errata/IMX7DS_3N09P.pdf). " ERR007805 I2C: When the I2C clock speed is configured for 400 kHz, the SCL low period violates the I2C spec of 1.3 uS min Description: When the I2C module is programmed to operate at the maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL clock low period violates the I2C spec of 1.3 uS min. The user must reduce the clock speed to obtain the SCL low time to meet the 1.3us I2C minimum required. This behavior means the SoC is not compliant to the I2C spec at 400kHz. Workaround: To meet the clock low period requirement in fast speed mode, SCL must be configured to 384KHz or less. " "fsl,imx7d-i2c" already is documented in binding doc. This erratum fix has been included in imx6_i2c_hwdata and it is the same in all I.MX6/7/8, so just reuse it. Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") Cc: [email protected] # v5.18+ Signed-off-by: Carlos Song <[email protected]> Signed-off-by: Haibo Chen <[email protected]> Reviewed-by: Frank Li <[email protected]> Fixes: 39c025721d70 ("i2c: imx: Implement errata ERR007805 or e7805 bus frequency limit") Acked-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Conor Dooley <[email protected]> Date: Wed Dec 18 12:07:40 2024 +0000 i2c: microchip-core: actually use repeated sends commit 9a8f9320d67b27ddd7f1ee88d91820197a0e908f upstream. At present, where repeated sends are intended to be used, the i2c-microchip-core driver sends a stop followed by a start. Lots of i2c devices must not malfunction in the face of this behaviour, because the driver has operated like this for years! Try to keep track of whether or not a repeated send is required, and suppress sending a stop in these cases. CC: [email protected] Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/20241218-football-composure-e56df2461461@spud Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Conor Dooley <[email protected]> Date: Wed Dec 18 12:07:42 2024 +0000 i2c: microchip-core: fix "ghost" detections commit 49e1f0fd0d4cb03a16b8526c4e683e1958f71490 upstream. Running i2c-detect currently produces an output akin to: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: 08 -- 0a -- 0c -- 0e -- 10: 10 -- 12 -- 14 -- 16 -- UU 19 -- 1b -- 1d -- 1f 20: -- 21 -- 23 -- 25 -- 27 -- 29 -- 2b -- 2d -- 2f 30: -- -- -- -- -- -- -- -- 38 -- 3a -- 3c -- 3e -- 40: 40 -- 42 -- 44 -- 46 -- 48 -- 4a -- 4c -- 4e -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: 60 -- 62 -- 64 -- 66 -- 68 -- 6a -- 6c -- 6e -- 70: 70 -- 72 -- 74 -- 76 -- This happens because for an i2c_msg with a len of 0 the driver will mark the transmission of the message as a success once the START has been sent, without waiting for the devices on the bus to respond with an ACK/NAK. Since i2cdetect seems to run in a tight loop over all addresses the NAK is treated as part of the next test for the next address. Delete the fast path that marks a message as complete when idev->msg_len is zero after sending a START/RESTART since this isn't a valid scenario. CC: [email protected] Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://lore.kernel.org/r/20241218-outbid-encounter-b2e78b1cc707@spud Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Thu Dec 26 16:49:23 2024 +0000 io_uring/sqpoll: fix sqpoll error handling races commit e33ac68e5e21ec1292490dfe061e75c0dbdd3bd4 upstream. BUG: KASAN: slab-use-after-free in __lock_acquire+0x370b/0x4a10 kernel/locking/lockdep.c:5089 Call Trace: <TASK> ... _raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb5/0x23c0 kernel/sched/core.c:4205 io_sq_thread_park+0xac/0xe0 io_uring/sqpoll.c:55 io_sq_thread_finish+0x6b/0x310 io_uring/sqpoll.c:96 io_sq_offload_create+0x162/0x11d0 io_uring/sqpoll.c:497 io_uring_create io_uring/io_uring.c:3724 [inline] io_uring_setup+0x1728/0x3230 io_uring/io_uring.c:3806 ... Kun Hu reports that the SQPOLL creating error path has UAF, which happens if io_uring_alloc_task_context() fails and then io_sq_thread() manages to run and complete before the rest of error handling code, which means io_sq_thread_finish() is looking at already killed task. Note that this is mostly theoretical, requiring fault injection on the allocation side to trigger in practice. Cc: [email protected] Reported-by: Kun Hu <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/0f2f1aa5729332612bd01fe0f2f385fd1f06ce7c.1735231717.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Thu Jan 2 10:32:11 2025 +0100 Linux 6.6.69 Link: https://lore.kernel.org/r/[email protected] Tested-by: Florian Fainelli <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: kernelci.org bot <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Harshit Mogalapalli <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Ron Economos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Mon Dec 2 16:42:08 2024 +0800 LoongArch: BPF: Adjust the parameter of emit_jirl() [ Upstream commit c1474bb0b7cff4e8481095bd0618b8f6c2f0aeb4 ] The branch instructions beq, bne, blt, bge, bltu, bgeu and jirl belong to the format reg2i16, but the sequence of oprand is different for the instruction jirl. So adjust the parameter order of emit_jirl() to make it more readable correspond with the Instruction Set Architecture manual. Here are the instruction formats: beq rj, rd, offs16 bne rj, rd, offs16 blt rj, rd, offs16 bge rj, rd, offs16 bltu rj, rd, offs16 bgeu rj, rd, offs16 jirl rd, rj, offs16 Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#branch-instructions Suggested-by: Huacai Chen <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huacai Chen <[email protected]> Date: Mon Dec 2 16:42:07 2024 +0800 LoongArch: Fix reserving screen info memory for above-4G firmware [ Upstream commit 55dc2f8f263448f1e6c7ef135d08e640d5a4826e ] Since screen_info.lfb_base is a __u32 type, an above-4G address need an ext_lfb_base to present its higher 32bits. In init_screen_info() we can use __screen_info_lfb_base() to handle this case for reserving screen info memory. Signed-off-by: Xuefeng Zhao <[email protected]> Signed-off-by: Jianmin Lv <[email protected]> Signed-off-by: Tianyang Zhang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Fri May 17 08:58:00 2024 -0700 media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg [ Upstream commit 2dd59fe0e19e1ab955259978082b62e5751924c7 ] Syzbot reports [1] an uninitialized value issue found by KMSAN in dib3000_read_reg(). Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case that call fails, the buffer may end up with some undefined values. Since no elaborate error handling is expected in dib3000_write_reg(), simply zero out rb buffer to mitigate the problem. [1] Syzkaller report dvb-usb: bulk message failed: -22 (6/0) ===================================================== BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110 ... Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 ... Fixes: 74340b0a8bc6 ("V4L/DVB (4457): Remove dib3000-common-module") Reported-by: [email protected] Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiaxun Yang <[email protected]> Date: Tue Dec 24 14:22:39 2024 +0800 MIPS: mipsregs: Set proper ISA level for virt extensions [ Upstream commit a640d6762a7d404644201ebf6d2a078e8dc84f97 ] c994a3ec7ecc ("MIPS: set mips32r5 for virt extensions") setted some instructions in virt extensions to ISA level mips32r5. However TLB related vz instructions was leftover, also this shouldn't be done to a R5 or R6 kernel buid. Reorg macros to set ISA level as needed when _ASM_SET_VIRT is called. Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: WangYuli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiaxun Yang <[email protected]> Date: Tue Dec 24 14:09:18 2024 +0800 MIPS: Probe toolchain support of -msym32 [ Upstream commit 18ca63a2e23c5e170d2d7552b64b1f5ad019cd9b ] msym32 is not supported by LLVM toolchain. Workaround by probe toolchain support of msym32 for KBUILD_SYM32 feature. Link: https://github.com/ClangBuiltLinux/linux/issues/1544 Signed-off-by: Jiaxun Yang <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: WangYuli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Thu Dec 12 13:31:26 2024 -0800 mm/vmstat: fix a W=1 clang compiler warning [ Upstream commit 30c2de0a267c04046d89e678cc0067a9cfb455df ] Fix the following clang compiler warning that is reported if the kernel is built with W=1: ./include/linux/vmstat.h:518:36: error: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Werror,-Wenum-enum-conversion] 518 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ Link: https://lkml.kernel.org/r/[email protected] Fixes: 9d7ea9a297e6 ("mm/vmstat: add helpers to get vmstat item names for each enum type") Signed-off-by: Bart Van Assche <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Nathan Chancellor <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zichen Xie <[email protected]> Date: Wed Oct 23 16:13:10 2024 -0500 mtd: diskonchip: Cast an operand to prevent potential overflow commit 9b458e8be0d13e81ed03fffa23f8f9b528bbd786 upstream. There may be a potential integer overflow issue in inftl_partscan(). parts[0].size is defined as "uint64_t" while mtd->erasesize and ip->firstUnit are defined as 32-bit unsigned integer. The result of the calculation will be limited to 32 bits without correct casting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Zichen Xie <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maciej Andrzejewski <[email protected]> Date: Mon Dec 2 13:51:07 2024 +0100 mtd: rawnand: arasan: Fix double assertion of chip-select commit b086a46dae48829e11c0c02580e30d920b76743c upstream. When two chip-selects are configured in the device tree, and the second is a non-native GPIO, both the GPIO-based chip-select and the first native chip-select may be asserted simultaneously. This double assertion causes incorrect read and write operations. The issue occurs because when nfc->ncs <= 2, nfc->spare_cs is always initialized to 0 due to static initialization. Consequently, when the second chip-select (GPIO-based) is selected in anfc_assert_cs(), it is detected by anfc_is_gpio_cs(), and nfc->native_cs is assigned the value 0. This results in both the GPIO-based chip-select being asserted and the NAND controller register receiving 0, erroneously selecting the native chip-select. This patch resolves the issue, as confirmed by oscilloscope testing with configurations involving two or more chip-selects in the device tree. Fixes: acbd3d0945f9 ("mtd: rawnand: arasan: Leverage additional GPIO CS") Cc: [email protected] Signed-off-by: Maciej Andrzejewski <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maciej Andrzejewski <[email protected]> Date: Mon Dec 2 19:58:36 2024 +0100 mtd: rawnand: arasan: Fix missing de-registration of NAND commit 11e6831fd81468cf48155b9b3c11295c391da723 upstream. The NAND chip-selects are registered for the Arasan driver during initialization but are not de-registered when the driver is unloaded. As a result, if the driver is loaded again, the chip-selects remain registered and busy, making them unavailable for use. Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller") Cc: [email protected] Signed-off-by: Maciej Andrzejewski ICEYE <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Oct 23 11:40:56 2024 +0300 mtd: rawnand: fix double free in atmel_pmecc_create_user() commit d8e4771f99c0400a1873235704b28bb803c83d17 upstream. The "user" pointer was converted from being allocated with kzalloc() to being allocated by devm_kzalloc(). Calling kfree(user) will lead to a double free. Fixes: 6d734f1bfc33 ("mtd: rawnand: atmel: Fix possible memory leak") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: NeilBrown <[email protected]> Date: Fri Dec 20 15:28:18 2024 +1100 nfsd: restore callback functionality for NFSv4.0 [ Upstream commit 7917f01a286ce01e9c085e24468421f596ee1a0c ] A recent patch inadvertently broke callbacks for NFSv4.0. In the 4.0 case we do not expect a session to be found but still need to call setup_callback_client() which will not try to dereference it. This patch moves the check for failure to find a session into the 4.1+ branch of setup_callback_client() Fixes: 1e02c641c3a4 ("NFSD: Prevent NULL dereference in nfsd4_process_cb_update()") Signed-off-by: NeilBrown <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Erkun <[email protected]> Date: Mon Dec 16 22:21:52 2024 +0800 nfsd: Revert "nfsd: release svc_expkey/svc_export with rcu_work" [ Upstream commit 69d803c40edeaf94089fbc8751c9b746cdc35044 ] This reverts commit f8c989a0c89a75d30f899a7cabdc14d72522bb8d. Before this commit, svc_export_put or expkey_put will call path_put with sync mode. After this commit, path_put will be called with async mode. And this can lead the unexpected results show as follow. mkfs.xfs -f /dev/sda echo "/ *(rw,no_root_squash,fsid=0)" > /etc/exports echo "/mnt *(rw,no_root_squash,fsid=1)" >> /etc/exports exportfs -ra service nfs-server start mount -t nfs -o vers=4.0 127.0.0.1:/mnt /mnt1 mount /dev/sda /mnt/sda touch /mnt1/sda/file exportfs -r umount /mnt/sda # failed unexcepted The touch will finally call nfsd_cross_mnt, add refcount to mount, and then add cache_head. Before this commit, exportfs -r will call cache_flush to cleanup all cache_head, and path_put in svc_export_put/expkey_put will be finished with sync mode. So, the latter umount will always success. However, after this commit, path_put will be called with async mode, the latter umount may failed, and if we add some delay, umount will success too. Personally I think this bug and should be fixed. We first revert before bugfix patch, and then fix the original bug with a different way. Fixes: f8c989a0c89a ("nfsd: release svc_expkey/svc_export with rcu_work") Signed-off-by: Yang Erkun <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Sat Dec 14 12:50:18 2024 +0100 PCI/MSI: Handle lack of irqdomain gracefully commit a60b990798eb17433d0283788280422b1bd94b18 upstream. Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a RISCV platform which does not provide PCI/MSI support: WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32 __pci_enable_msix_range+0x30c/0x596 pci_msi_setup_msi_irqs+0x2c/0x32 pci_alloc_irq_vectors_affinity+0xb8/0xe2 RISCV uses hierarchical interrupt domains and correctly does not implement the legacy fallback. The warning triggers from the legacy fallback stub. That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent domain is associated with the device or not. There is a check for MSI-X, which has a legacy assumption. But that legacy fallback assumption is only valid when legacy support is enabled, but otherwise the check should simply return -ENOTSUPP. Loongarch tripped over the same problem and blindly enabled legacy support without implementing the legacy fallbacks. There are weak implementations which return an error, so the problem was papered over. Correct pci_msi_domain_supports() to evaluate the legacy mode and add the missing supported check into the MSI enable path to complete it. Fixes: d2a463b29741 ("PCI/MSI: Reject multi-MSI early") Reported-by: Alexandre Ghiti <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Alexandre Ghiti <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/87ed2a8ow5.ffs@tglx Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Fri Dec 13 20:36:44 2024 +0800 phy: core: Fix an OF node refcount leakage in _of_phy_get() commit 5ebdc6be16c2000e37fcb8b4072d442d268ad492 upstream. _of_phy_get() will directly return when suffers of_device_is_compatible() error, but it forgets to decrease refcount of OF node @args.np before error return, the refcount was increased by previous of_parse_phandle_with_args() so causes the OF node's refcount leakage. Fix by decreasing the refcount via of_node_put() before the error return. Fixes: b7563e2796f8 ("phy: work around 'phys' references to usb-nop-xceiv devices") Cc: [email protected] Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Fri Dec 13 20:36:45 2024 +0800 phy: core: Fix an OF node refcount leakage in of_phy_provider_lookup() commit a2d633cb1421e679b56f1a9fe1f42f089706f1ed upstream. For macro for_each_child_of_node(parent, child), refcount of @child has been increased before entering its loop body, so normally needs to call of_node_put(@child) before returning from the loop body to avoid refcount leakage. of_phy_provider_lookup() has such usage but does not call of_node_put() before returning, so cause leakage of the OF node refcount. Fix by simply calling of_node_put() before returning from the loop body. The APIs affected by this issue are shown below since they indirectly invoke problematic of_phy_provider_lookup(). phy_get() of_phy_get() devm_phy_get() devm_of_phy_get() devm_of_phy_get_by_index() Fixes: 2a4c37016ca9 ("phy: core: Fix of_phy_provider_lookup to return PHY provider for sub node") Cc: [email protected] Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Fri Dec 13 20:36:42 2024 +0800 phy: core: Fix that API devm_of_phy_provider_unregister() fails to unregister the phy provider commit c0b82ab95b4f1fbc3e3aeab9d829d012669524b6 upstream. For devm_of_phy_provider_unregister(), its comment says it needs to invoke of_phy_provider_unregister() to unregister the phy provider, but it will not actually invoke the function since devres_destroy() does not call devm_phy_provider_release(), and the missing of_phy_provider_unregister() call will cause: - The phy provider fails to be unregistered. - Leak both memory and the OF node refcount. Fortunately, the faulty API has not been used by current kernel tree. Fix by using devres_release() instead of devres_destroy() within the API. Fixes: ff764963479a ("drivers: phy: add generic PHY framework") Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/stable/20241213-phy_core_fix-v6-2-40ae28f5015a%40quicinc.com Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Fri Dec 13 20:36:43 2024 +0800 phy: core: Fix that API devm_phy_destroy() fails to destroy the phy commit 4dc48c88fcf82b89fdebd83a906aaa64f40fb8a9 upstream. For devm_phy_destroy(), its comment says it needs to invoke phy_destroy() to destroy the phy, but it will not actually invoke the function since devres_destroy() does not call devm_phy_consume(), and the missing phy_destroy() call will cause that the phy fails to be destroyed. Fortunately, the faulty API has not been used by current kernel tree. Fix by using devres_release() instead of devres_destroy() within the API. Fixes: ff764963479a ("drivers: phy: add generic PHY framework") Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zijun Hu <[email protected]> Date: Fri Dec 13 20:36:41 2024 +0800 phy: core: Fix that API devm_phy_put() fails to release the phy commit fe4bfa9b6d7bd752bfe4700c937f235aa8ce997b upstream. For devm_phy_put(), its comment says it needs to invoke phy_put() to release the phy, but it will not actually invoke the function since devres_destroy() does not call devm_phy_release(), and the missing phy_put() call will cause: - The phy fails to be released. - devm_phy_put() can not fully undo what API devm_phy_get() does. - Leak refcount of both the module and device for below typical usage: devm_phy_get(); // or its variant ... err = do_something(); if (err) goto err_out; ... err_out: devm_phy_put(); // leak refcount here The file(s) affected by this issue are shown below since they have such typical usage. drivers/pci/controller/cadence/pcie-cadence.c drivers/net/ethernet/ti/am65-cpsw-nuss.c Fix by using devres_release() instead of devres_destroy() within the API. Fixes: ff764963479a ("drivers: phy: add generic PHY framework") Cc: [email protected] Cc: Lorenzo Pieralisi <[email protected]> Cc: Krzysztof Wilczyński <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: David S. Miller <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Krishna Kurapati <[email protected]> Date: Tue Nov 12 14:58:31 2024 +0530 phy: qcom-qmp: Fix register name in RX Lane config of SC8280XP commit 8886fb3240931a0afce82dea87edfe46bcb0a586 upstream. In RX Lane configuration sequence of SC8280XP, the register V5_RX_UCDR_FO_GAIN is incorrectly spelled as RX_UCDR_SO_GAIN and hence the programming sequence is wrong. Fix the register sequence accordingly to avoid any compliance failures. This has been tested on SA8775P by checking device mode enumeration in SuperSpeed. Cc: [email protected] Fixes: c0c7769cdae2 ("phy: qcom-qmp: Add SC8280XP USB3 UNI phy") Signed-off-by: Krishna Kurapati <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chukun Pan <[email protected]> Date: Fri Nov 22 15:30:06 2024 +0800 phy: rockchip: naneng-combphy: fix phy reset commit fbcbffbac994aca1264e3c14da96ac9bfd90466e upstream. Currently, the USB port via combophy on the RK3528/RK3588 SoC is broken. usb usb8-port1: Cannot enable. Maybe the USB cable is bad? This is due to the combphy of RK3528/RK3588 SoC has multiple resets, but only "phy resets" need assert and deassert, "apb resets" don't need. So change the driver to only match the phy resets, which is also what the vendor kernel does. Fixes: 7160820d742a ("phy: rockchip: add naneng combo phy for RK3568") Cc: FUKAUMI Naoki <[email protected]> Cc: Michael Zimmermann <[email protected]> Signed-off-by: Chukun Pan <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: FUKAUMI Naoki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Justin Chen <[email protected]> Date: Thu Oct 24 14:35:40 2024 -0700 phy: usb: Toggle the PHY power during init commit 0a92ea87bdd6f77ca4e17fe19649882cf5209edd upstream. When bringing up the PHY, it might be in a bad state if left powered. One case is we lose the PLL lock if the PLL is gated while the PHY is powered. Toggle the PHY power so we can start from a known state. Fixes: 4e5b9c9a73b3 ("phy: usb: Add support for new Synopsys USB controller on the 7216") Signed-off-by: Justin Chen <[email protected]> Acked-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Armin Wolf <[email protected]> Date: Sat Nov 23 23:47:00 2024 +0100 platform/x86: asus-nb-wmi: Ignore unknown event 0xCF [ Upstream commit e9fba20c29e27dc99e55e1c550573a114561bf8c ] On the Asus X541UAK an unknown event 0xCF is emited when the charger is plugged in. This is caused by the following AML code: If (ACPS ()) { ACPF = One Local0 = 0x58 If (ATKP) { ^^^^ATKD.IANE (0xCF) } } Else { ACPF = Zero Local0 = 0x57 } Notify (AC0, 0x80) // Status Change If (ATKP) { ^^^^ATKD.IANE (Local0) } Sleep (0x64) PNOT () Sleep (0x0A) NBAT (0x80) Ignore the 0xCF event to silence the unknown event warning. Reported-by: Pau Espin Pedrol <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected] Signed-off-by: Armin Wolf <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ulf Hansson <[email protected]> Date: Fri Nov 22 14:42:02 2024 +0100 pmdomain: core: Add missing put_device() [ Upstream commit b8f7bbd1f4ecff6d6277b8c454f62bb0a1c6dbe4 ] When removing a genpd we don't clean up the genpd->dev correctly. Let's add the missing put_device() in genpd_free_data() to fix this. Fixes: 401ea1572de9 ("PM / Domain: Add struct device to genpd") Cc: [email protected] Signed-off-by: Ulf Hansson <[email protected]> Message-ID: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dimitri Fedrau <[email protected]> Date: Mon Dec 9 11:46:15 2024 +0100 power: supply: gpio-charger: Fix set charge current limits commit afc6e39e824ad0e44b2af50a97885caec8d213d1 upstream. Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. Fixes: be2919d8355e ("power: supply: gpio-charger: add charge-current-limit feature") Cc: [email protected] Signed-off-by: Dimitri Fedrau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Haren Myneni <[email protected]> Date: Fri Dec 13 21:17:58 2024 -0800 powerpc/pseries/vas: Add close() callback in vas_vm_ops struct [ Upstream commit 05aa156e156ef3168e7ab8a68721945196495c17 ] The mapping VMA address is saved in VAS window struct when the paste address is mapped. This VMA address is used during migration to unmap the paste address if the window is active. The paste address mapping will be removed when the window is closed or with the munmap(). But the VMA address in the VAS window is not updated with munmap() which is causing invalid access during migration. The KASAN report shows: [16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8 [16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928 [16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2 [16386.255128] Tainted: [B]=BAD_PAGE [16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries [16386.255181] Call Trace: [16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable) [16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764 [16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8 [16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0 [16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8 [16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc [16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4 ... [16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s: [16386.256149] kasan_save_stack+0x34/0x68 [16386.256163] kasan_save_track+0x34/0x80 [16386.256175] kasan_save_alloc_info+0x58/0x74 [16386.256196] __kasan_slab_alloc+0xb8/0xdc [16386.256209] kmem_cache_alloc_noprof+0x200/0x3d0 [16386.256225] vm_area_alloc+0x44/0x150 [16386.256245] mmap_region+0x214/0x10c4 [16386.256265] do_mmap+0x5fc/0x750 [16386.256277] vm_mmap_pgoff+0x14c/0x24c [16386.256292] ksys_mmap_pgoff+0x20c/0x348 [16386.256303] sys_mmap+0xd0/0x160 ... [16386.256350] Freed by task 0 on cpu 31 at 16386.204848s: [16386.256363] kasan_save_stack+0x34/0x68 [16386.256374] kasan_save_track+0x34/0x80 [16386.256384] kasan_save_free_info+0x64/0x10c [16386.256396] __kasan_slab_free+0x120/0x204 [16386.256415] kmem_cache_free+0x128/0x450 [16386.256428] vm_area_free_rcu_cb+0xa8/0xd8 [16386.256441] rcu_do_batch+0x2c8/0xcf0 [16386.256458] rcu_core+0x378/0x3c4 [16386.256473] handle_softirqs+0x20c/0x60c [16386.256495] do_softirq_own_stack+0x6c/0x88 [16386.256509] do_softirq_own_stack+0x58/0x88 [16386.256521] __irq_exit_rcu+0x1a4/0x20c [16386.256533] irq_exit+0x20/0x38 [16386.256544] interrupt_async_exit_prepare.constprop.0+0x18/0x2c ... [16386.256717] Last potentially related work creation: [16386.256729] kasan_save_stack+0x34/0x68 [16386.256741] __kasan_record_aux_stack+0xcc/0x12c [16386.256753] __call_rcu_common.constprop.0+0x94/0xd04 [16386.256766] vm_area_free+0x28/0x3c [16386.256778] remove_vma+0xf4/0x114 [16386.256797] do_vmi_align_munmap.constprop.0+0x684/0x870 [16386.256811] __vm_munmap+0xe0/0x1f8 [16386.256821] sys_munmap+0x54/0x6c [16386.256830] system_call_exception+0x1a0/0x4a0 [16386.256841] system_call_vectored_common+0x15c/0x2ec [16386.256868] The buggy address belongs to the object at c00000014a819670 which belongs to the cache vm_area_struct of size 168 [16386.256887] The buggy address is located 0 bytes inside of freed 168-byte region [c00000014a819670, c00000014a819718) [16386.256915] The buggy address belongs to the physical page: [16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81 [16386.256950] memcg:c0000000ba430001 [16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff) [16386.256975] page_type: 0xfdffffff(slab) [16386.256990] raw: 043ffff800000000 c00000000501c080 0000000000000000 5deadbee00000001 [16386.257003] raw: 0000000000000000 00000000011a011a 00000001fdffffff c0000000ba430001 [16386.257018] page dumped because: kasan: bad access detected This patch adds close() callback in vas_vm_ops vm_operations_struct which will be executed during munmap() before freeing VMA. The VMA address in the VAS window is set to NULL after holding the window mmap_mutex. Fixes: 37e6764895ef ("powerpc/pseries/vas: Add VAS migration handler") Signed-off-by: Haren Myneni <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Wed Nov 27 13:35:06 2024 +0000 regmap: Use correct format specifier for logging range errors [ Upstream commit 3f1aa0c533d9dd8a835caf9a6824449c463ee7e2 ] The register addresses are unsigned ints so we should use %u not %d to log them. Signed-off-by: Mark Brown <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qun-Wei Lin <[email protected]> Date: Tue Dec 24 16:10:57 2024 +0800 sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers [ Upstream commit fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 ] When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qun-Wei Lin <[email protected]> Cc: Andrew Yang <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Casper Li <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Pasha Tatashin <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> [ Resolve line conflicts ] Signed-off-by: Wenshan Lan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tomas Henzl <[email protected]> Date: Mon Sep 23 19:48:33 2024 +0200 scsi: megaraid_sas: Fix for a potential deadlock [ Upstream commit 50740f4dc78b41dec7c8e39772619d5ba841ddd7 ] This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. Signed-off-by: Tomas Henzl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Chandrakanth Patil <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Sun Nov 10 23:03:40 2024 +0530 scsi: mpt3sas: Diag-Reset when Doorbell-In-Use bit is set during driver load time [ Upstream commit 3f5eb062e8aa335643181c480e6c590c6cedfd22 ] Issue a Diag-Reset when the "Doorbell-In-Use" bit is set during the driver load/initialization. Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Magnus Lindholm <[email protected]> Date: Wed Nov 13 23:51:49 2024 +0100 scsi: qla1280: Fix hw revision numbering for ISP1020/1040 [ Upstream commit c064de86d2a3909222d5996c5047f64c7a8f791b ] Fix the hardware revision numbering for Qlogic ISP1020/1040 boards. HWMASK suggests that the revision number only needs four bits, this is consistent with how NetBSD does things in their ISP driver. Verified on a IPS1040B which is seen as rev 5 not as BIT_4. Signed-off-by: Magnus Lindholm <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cathy Avery <[email protected]> Date: Wed Nov 27 13:13:24 2024 -0500 scsi: storvsc: Do not flag MAINTENANCE_IN return of SRB_STATUS_DATA_OVERRUN as an error [ Upstream commit b1aee7f034615b6824d2c70ddb37ef9fc23493b7 ] This partially reverts commit 812fe6420a6e ("scsi: storvsc: Handle additional SRB status values"). HyperV does not support MAINTENANCE_IN resulting in FC passthrough returning the SRB_STATUS_DATA_OVERRUN value. Now that SRB_STATUS_DATA_OVERRUN is treated as an error, multipath ALUA paths go into a faulty state as multipath ALUA submits RTPG commands via MAINTENANCE_IN. [ 3.215560] hv_storvsc 1d69d403-9692-4460-89f9-a8cbcc0f94f3: tag#230 cmd 0xa3 status: scsi 0x0 srb 0x12 hv 0xc0000001 [ 3.215572] scsi 1:0:0:32: alua: rtpg failed, result 458752 Make MAINTENANCE_IN return success to avoid the error path as is currently done with INQUIRY and MODE_SENSE. Suggested-by: Michael Kelley <[email protected]> Signed-off-by: Cathy Avery <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Michael Kelley <[email protected]> Reviewed-by: Ewan D. Milne <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brahmajit Das <[email protected]> Date: Tue Nov 26 11:41:35 2024 +0530 smb: server: Fix building with GCC 15 [ Upstream commit e18655cf35a5958fbf4ae9ca3ebf28871a3a1801 ] GCC 15 introduces -Werror=unterminated-string-initialization by default, this results in the following build error fs/smb/server/smb_common.c:21:35: error: initializer-string for array of 'char' is too long [-Werror=unterminated-string-ini tialization] 21 | static const char basechars[43] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_-!@#$%"; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors To this we are replacing char basechars[43] with a character pointer and then using strlen to get the length. Signed-off-by: Brahmajit Das <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aapo Vienamo <[email protected]> Date: Wed Dec 4 10:02:08 2024 +0200 spi: intel: Add Panther Lake SPI controller support [ Upstream commit ceb259e43bf572ba7d766e1679ba73861d16203a ] The Panther Lake SPI controllers are compatible with the Cannon Lake controllers. Add support for following SPI controller device IDs: - H-series: 0xe323 - P-series: 0xe423 - U-series: 0xe423 Signed-off-by: Aapo Vienamo <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Purushothama Siddaiah <[email protected]> Date: Thu Dec 5 12:34:26 2024 +0530 spi: omap2-mcspi: Fix the IS_ERR() bug for devm_clk_get_optional_enabled() [ Upstream commit 4c6ac5446d060f0bf435ccc8bc3aa7b7b5f718ad ] The devm_clk_get_optional_enabled() function returns error pointers(PTR_ERR()). So use IS_ERR() to check it. Verified on K3-J7200 EVM board, without clock node mentioned in the device tree. Signed-off-by: Purushothama Siddaiah <[email protected]> Reviewed-by: Corey Minyard <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Thu Dec 19 14:57:34 2024 +0100 stddef: make __struct_group() UAPI C++-friendly [ Upstream commit 724c6ce38bbaeb4b3f109b0e066d6c0ecd15446c ] For the most part of the C++ history, it couldn't have type declarations inside anonymous unions for different reasons. At the same time, __struct_group() relies on the latters, so when the @TAG argument is not empty, C++ code doesn't want to build (even under `extern "C"`): ../linux/include/uapi/linux/pkt_cls.h:25:24: error: 'struct tc_u32_sel::<unnamed union>::tc_u32_sel_hdr,' invalid; an anonymous union may only have public non-static data members [-fpermissive] The safest way to fix this without trying to switch standards (which is impossible in UAPI anyway) etc., is to disable tag declaration for that language. This won't break anything since for now it's not buildable at all. Use a separate definition for __struct_group() when __cplusplus is defined to mitigate the error, including the version from tools/. Fixes: 50d7bd38c3aa ("stddef: Introduce struct_group() helper macro") Reported-by: Christopher Ferris <[email protected]> Closes: https://lore.kernel.org/linux-hardening/[email protected] Suggested-by: Kees Cook <[email protected]> # __struct_group_tag() Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijian Zhang <[email protected]> Date: Tue Dec 10 01:20:39 2024 +0000 tcp_bpf: Add sk_rmem_alloc related logic for tcp_bpf ingress redirection [ Upstream commit d888b7af7c149c115dd6ac772cc11c375da3e17c ] When we do sk_psock_verdict_apply->sk_psock_skb_ingress, an sk_msg will be created out of the skb, and the rmem accounting of the sk_msg will be handled by the skb. For skmsgs in __SK_REDIRECT case of tcp_bpf_send_verdict, when redirecting to the ingress of a socket, although we sk_rmem_schedule and add sk_msg to the ingress_msg of sk_redir, we do not update sk_rmem_alloc. As a result, except for the global memory limit, the rmem of sk_redir is nearly unlimited. Thus, add sk_rmem_alloc related logic to limit the recv buffer. Since the function sk_msg_recvmsg and __sk_psock_purge_ingress_msg are used in these two paths. We use "msg->skb" to test whether the sk_msg is skb backed up. If it's not, we shall do the memory accounting explicitly. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Zijian Zhang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Cong Wang <[email protected]> Date: Tue Dec 10 01:20:38 2024 +0000 tcp_bpf: Charge receive socket buffer in bpf_tcp_ingress() [ Upstream commit 54f89b3178d5448dd4457afbb98fc1ab99090a65 ] When bpf_tcp_ingress() is called, the skmsg is being redirected to the ingress of the destination socket. Therefore, we should charge its receive socket buffer, instead of sending socket buffer. Because sk_rmem_schedule() tests pfmemalloc of skb, we need to introduce a wrapper and call it for skmsg. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Cong Wang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Wed Dec 11 09:10:55 2024 +0900 tracing/kprobe: Make trace_kprobe's module callback called after jump_label update [ Upstream commit d685d55dfc86b1a4bdcec77c3c1f8a83f181264e ] Make sure the trace_kprobe's module notifer callback function is called after jump_label's callback is called. Since the trace_kprobe's callback eventually checks jump_label address during registering new kprobe on the loading module, jump_label must be updated before this registration happens. Link: https://lore.kernel.org/all/173387585556.995044.3157941002975446119.stgit@devnote2/ Fixes: 614243181050 ("tracing/kprobes: Support module init function probing") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Göttsche <[email protected]> Date: Mon Nov 25 11:50:25 2024 +0100 tracing: Constify string literal data member in struct trace_event_call commit 452f4b31e3f70a52b97890888eeb9eaa9a87139a upstream. The name member of the struct trace_event_call is assigned with generated string literals; declare them pointer to read-only. Reported by clang: security/landlock/syscalls.c:179:1: warning: initializing 'char *' with an expression of type 'const char[34]' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] 179 | SYSCALL_DEFINE3(landlock_create_ruleset, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 180 | const struct landlock_ruleset_attr __user *const, attr, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 181 | const size_t, size, const __u32, flags) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/syscalls.h:226:36: note: expanded from macro 'SYSCALL_DEFINE3' 226 | #define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/syscalls.h:234:2: note: expanded from macro 'SYSCALL_DEFINEx' 234 | SYSCALL_METADATA(sname, x, __VA_ARGS__) \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/syscalls.h:184:2: note: expanded from macro 'SYSCALL_METADATA' 184 | SYSCALL_TRACE_ENTER_EVENT(sname); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/syscalls.h:151:30: note: expanded from macro 'SYSCALL_TRACE_ENTER_EVENT' 151 | .name = "sys_enter"#sname, \ | ^~~~~~~~~~~~~~~~~ Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Mickaël Salaün <[email protected]> Cc: Günther Noack <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Bill Wendling <[email protected]> Cc: Justin Stitt <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: b77e38aa240c3 ("tracing: add event trace infrastructure") Signed-off-by: Christian Göttsche <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lizhi Xu <[email protected]> Date: Mon Dec 16 15:32:38 2024 +0800 tracing: Prevent bad count for tracing_cpumask_write commit 98feccbf32cfdde8c722bc4587aaa60ee5ac33f0 upstream. If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it. Cc: [email protected] Fixes: 9e01c1b74c953 ("cpumask: convert kernel trace functions") Link: https://lore.kernel.org/[email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=0aecfd34fb878546f3fd Tested-by: [email protected] Signed-off-by: Lizhi Xu <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Nov 26 12:46:00 2024 +0100 udf: Skip parent dir link count update if corrupted [ Upstream commit c5566903af56dd1abb092f18dcb0c770d6cd8dcb ] If the parent directory link count is too low (likely directory inode corruption), just skip updating its link count as if it goes to 0 too early it can cause unexpected issues. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Tue Nov 12 20:58:21 2024 +0800 virtio-blk: don't keep queue frozen during system suspend [ Upstream commit 7678abee0867e6b7fb89aa40f6e9f575f755fb37 ] Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/[email protected]/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend. Cc: Yi Sun <[email protected]> Cc: Michael S. Tsirkin <[email protected]> Cc: Jason Wang <[email protected]> Cc: Stefan Hajnoczi <[email protected]> Cc: [email protected] Reported-by: Marek Szyprowski <[email protected]> Signed-off-by: Ming Lei <[email protected]> Acked-by: Stefan Hajnoczi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Hilliard <[email protected]> Date: Fri Oct 25 00:34:40 2024 -0600 watchdog: it87_wdt: add PWRGD enable quirk for Qotom QCML04 [ Upstream commit 43439076383a7611300334d1357c0f8883f40816 ] For the watchdog timer to work properly on the QCML04 board we need to set PWRGD enable in the Environment Controller Configuration Registers Special Configuration Register 1 when it is not already set, this may be the case when the watchdog is not enabled from within the BIOS. Signed-off-by: James Hilliard <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yassine Oudjana <[email protected]> Date: Wed Nov 6 10:47:55 2024 +0000 watchdog: mediatek: Add support for MT6735 TOPRGU/WDT [ Upstream commit 15ddf704f56f8c95ff74dfd1157ed8646b322fa1 ] Add support for the Top Reset Generation Unit/Watchdog Timer found on MT6735. Signed-off-by: Yassine Oudjana <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrew Cooper <[email protected]> Date: Wed May 29 19:36:05 2024 +0100 x86/cpu/intel: Drop stray FAM6 check with new Intel CPU model defines commit 34b3fc558b537bdf99644dcde539e151716f6331 upstream. The outer if () should have been dropped when switching to c->x86_vfm. Fixes: 6568fc18c2f6 ("x86/cpu/intel: Switch to new Intel CPU model defines") Signed-off-by: Andrew Cooper <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Acked-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tony Luck <[email protected]> Date: Mon May 20 15:45:59 2024 -0700 x86/cpu/intel: Switch to new Intel CPU model defines [ Upstream commit 6568fc18c2f62b4f35092e9680fe39f3500f4767 ] New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Link: https://lore.kernel.org/all/20240520224620.9480-29-tony.luck%40intel.com Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation") Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Luck <[email protected]> Date: Tue Apr 16 14:19:03 2024 -0700 x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 [ Upstream commit a9d0adce69075192961f3be466c4810a21b7bc9e ] Refactor struct cpuinfo_x86 so that the vendor, family, and model fields are overlaid in a union with a 32-bit field that combines all three (together with a one byte reserved field in the upper byte). This will make it easy, cheap, and reliable to check all three values at once. See https://lore.kernel.org/r/Zgr6kT8oULbnmEXx@agluck-desk3 for why the ordering is (low-to-high bits): (vendor, family, model) [ bp: Move comments over the line, add the backstory about the particular order of the fields. ] Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation") Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Luck <[email protected]> Date: Tue Apr 16 14:19:05 2024 -0700 x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h [ Upstream commit f055b6260eb3ef20a6e310d1e555a5d5a0a28ca0 ] New CPU #defines encode vendor and family as well as model. Update the example usage comment in arch/x86/kernel/cpu/match.c Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation") Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Tue Nov 12 21:07:00 2024 -0500 x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation [ Upstream commit c9a4b55431e5220347881e148725bed69c84e037 ] Under some conditions, MONITOR wakeups on Lunar Lake processors can be lost, resulting in significant user-visible delays. Add Lunar Lake to X86_BUG_MONITOR so that wake_up_idle_cpu() always sends an IPI, avoiding this potential delay. Reported originally here: https://bugzilla.kernel.org/show_bug.cgi?id=219364 [ dhansen: tweak subject ] Signed-off-by: Len Brown <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Rafael J. Wysocki <[email protected]> Cc:[email protected] Link: https://lore.kernel.org/all/a4aa8842a3c3bfdb7fe9807710eef159cbf0e705.1731463305.git.len.brown%40intel.com Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Luck <[email protected]> Date: Fri Mar 22 09:17:25 2024 -0700 x86/cpu: Add model number for another Intel Arrow Lake mobile processor [ Upstream commit 8a8a9c9047d1089598bdb010ec44d7f14b4f9203 ] This one is the regular laptop CPU. Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation") Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Luck <[email protected]> Date: Wed Jan 17 11:18:44 2024 -0800 x86/cpu: Add model number for Intel Clearwater Forest processor [ Upstream commit 090e3bec01763e415bccae445f5bfe3d0c61b629 ] Server product based on the Atom Darkmont core. Signed-off-by: Tony Luck <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: c9a4b55431e5 ("x86/cpu: Add Lunar Lake to list of CPUs with a broken MONITOR implementation") Signed-off-by: Sasha Levin <[email protected]>