commit d29de02effd4e8816333582ed8230d41e14a73dc Author: Greg Kroah-Hartman Date: Sat Aug 3 09:01:09 2024 +0200 Linux 6.10.3 Link: https://lore.kernel.org/r/20240730151724.637682316@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Mark Brown Link: https://lore.kernel.org/r/20240731073248.306752137@linuxfoundation.org Link: https://lore.kernel.org/r/20240731095022.970699670@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Mark Brown Tested-by: Luna Jernberg Tested-by: Ronald Warsow Tested-by: Jon Hunter Tested-by: Christian Heusel Tested-by: Markus Reichelt Tested-by: Peter Schneider  Tested-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Allen Pais Tested-by: Florian Fainelli Tested-by: Jiri Slaby Tested-by: Ron Economos Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 979185d6ddfeaaa728ee935ebe8c4b9b06c1e5b8 Author: Daniel Borkmann Date: Fri Jul 12 18:12:30 2024 +0200 selftests/bpf: DENYLIST.aarch64: Skip fexit_sleep again commit 517125f6749402e579f715519147145944f12ad9 upstream. Revert commit 90dc946059b7 ("selftests/bpf: DENYLIST.aarch64: Remove fexit_sleep") again. The fix in 19d3c179a377 ("bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG") does not address all of the issues and BPF CI is still hanging and timing out: https://github.com/kernel-patches/bpf/actions/runs/9905842936/job/27366435436 [...] #89/11 fexit_bpf2bpf/func_replace_global_func:OK #89/12 fexit_bpf2bpf/fentry_to_cgroup_bpf:OK #89/13 fexit_bpf2bpf/func_replace_progmap:OK #89 fexit_bpf2bpf:OK Error: The operation was canceled. Thus more investigation work & fixing is needed before the test can be put in place again. Signed-off-by: Daniel Borkmann Cc: Puranjay Mohan Link: https://lore.kernel.org/bpf/20240705145009.32340-1-puranjay@kernel.org Signed-off-by: Greg Kroah-Hartman commit bc8ccc1f1e079aac885e4d62efaa63159bf2b7c8 Author: Paul Moore Date: Wed Jul 3 17:00:20 2024 -0400 selinux,smack: remove the capability checks in the removexattr hooks commit dd44477e7fa15ba3b100dfc67bf7cf083f3dccf6 upstream. Commit 61df7b828204 ("lsm: fixup the inode xattr capability handling") moved the responsibility of doing the inode xattr capability checking out of the individual LSMs and into the LSM framework itself. Unfortunately, while the original commit added the capability checks to both the setxattr and removexattr code in the LSM framework, it only removed the setxattr capability checks from the individual LSMs, leaving duplicated removexattr capability checks in both the SELinux and Smack code. This patch removes the duplicated code from SELinux and Smack. Fixes: 61df7b828204 ("lsm: fixup the inode xattr capability handling") Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit bb6841f96eb6f3285a3bfe40f31bcc578781eaa4 Author: Esben Haabendal Date: Thu May 30 16:46:37 2024 +0200 powerpc/configs: Update defconfig with now user-visible CONFIG_FSL_IFC commit 45547a0a93d85f704b49788cde2e1d9ab9cd363b upstream. With CONFIG_FSL_IFC now being user-visible, and thus changed from a select to depends in CONFIG_MTD_NAND_FSL_IFC, the dependencies needs to be selected in defconfigs. Depends-on: 9ba0cae3cac0 ("memory: fsl_ifc: Make FSL_IFC config visible and selectable") Signed-off-by: Esben Haabendal Reviewed-by: Krzysztof Kozlowski Signed-off-by: Michael Ellerman Link: https://msgid.link/20240530-fsl-ifc-config-v3-2-1fd2c3d233dd@geanix.com Signed-off-by: Greg Kroah-Hartman commit 1861a571928cc773b18534ebfe19b73e59a31479 Author: James Clark Date: Mon Jul 15 10:47:13 2024 +0100 perf dso: Fix build when libunwind is enabled [ Upstream commit 92717bc077892d1ce60fee07aee3a33f33909b85 ] Now that symsrc_filename is always accessed through an accessor, we also need a free() function for it to avoid the following compilation error: util/unwind-libunwind-local.c:416:12: error: lvalue required as unary ‘&’ operand 416 | zfree(&dso__symsrc_filename(dso)); Fixes: 1553419c3c10 ("perf dso: Fix address sanitizer build") Signed-off-by: James Clark Reviewed-by: Ian Rogers Tested-by: Leo Yan Tested-by: Florian Fainelli Cc: Yunseong Kim Cc: Athira Rajeev Link: https://lore.kernel.org/r/20240715094715.3914813-1-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6a424ef14fbcb85ac8211afd662850be0a072a33 Author: Karthikeyan Periyasamy Date: Thu Jun 13 21:08:13 2024 +0530 wifi: ath12k: fix mbssid max interface advertisement [ Upstream commit 253ec89c9013b0e61f5c54344df7c065d54934d1 ] The Current method for advertising the maximum MBSSID interface count assumes single radio per wiphy (multi wiphy model). However, this assumption is incorrect for multi radio per wiphy (single wiphy model). Therefore, populate the parameter for each radio present in the MAC abstraction layer (ah). This approach ensure scalability for both single wiphy and multi wiphy models. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: 519a545cfee7 ("wifi: ath12k: advertise driver capabilities for MBSSID and EMA") Signed-off-by: Karthikeyan Periyasamy Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240613153813.3509837-1-quic_periyasa@quicinc.com Signed-off-by: Sasha Levin commit 767d55c3f571cc3fe38bb552b49c3ea55b1f475d Author: Seth Forshee (DigitalOcean) Date: Wed Jul 24 09:53:59 2024 -0500 fs: don't allow non-init s_user_ns for filesystems without FS_USERNS_MOUNT [ Upstream commit e1c5ae59c0f22f7fe5c07fb5513a29e4aad868c9 ] Christian noticed that it is possible for a privileged user to mount most filesystems with a non-initial user namespace in sb->s_user_ns. When fsopen() is called in a non-init namespace the caller's namespace is recorded in fs_context->user_ns. If the returned file descriptor is then passed to a process priviliged in init_user_ns, that process can call fsconfig(fd_fs, FSCONFIG_CMD_CREATE), creating a new superblock with sb->s_user_ns set to the namespace of the process which called fsopen(). This is problematic. We cannot assume that any filesystem which does not set FS_USERNS_MOUNT has been written with a non-initial s_user_ns in mind, increasing the risk for bugs and security issues. Prevent this by returning EPERM from sget_fc() when FS_USERNS_MOUNT is not set for the filesystem and a non-initial user namespace will be used. sget() does not need to be updated as it always uses the user namespace of the current context, or the initial user namespace if SB_SUBMOUNT is set. Fixes: cb50b348c71f ("convenience helpers: vfs_get_super() and sget_fc()") Reported-by: Christian Brauner Signed-off-by: Seth Forshee (DigitalOcean) Link: https://lore.kernel.org/r/20240724-s_user_ns-fix-v1-1-895d07c94701@kernel.org Reviewed-by: Alexander Mikhalitsyn Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 70a449b162c4feee191028f68a97a5d7d88c684c Author: Jarkko Nikula Date: Fri Jun 14 17:02:08 2024 +0300 i3c: mipi-i3c-hci: Fix number of DAT/DCT entries for HCI versions < 1.1 [ Upstream commit be90ae1ba14a83962b33c4d4c854ef081186b0e4 ] I was wrong about the TABLE_SIZE field description in the commit 0676bfebf576 ("i3c: mipi-i3c-hci: Fix DAT/DCT entry sizes"). For the MIPI I3C HCI versions 1.0 and earlier the TABLE_SIZE field in the registers DAT_SECTION_OFFSET and DCT_SECTION_OFFSET is indeed defined in DWORDs and not number of entries like it is defined in later versions. Where above fix allowed driver initialization to continue the wrongly interpreted TABLE_SIZE field leads variables DAT_entries being twice and DCT_entries four times as big as they really are. That in turn leads clearing the DAT table over the boundary in the dat_v1.c: hci_dat_v1_init(). So interprete the TABLE_SIZE field in DWORDs for HCI versions < 1.1 and fix number of DAT/DCT entries accordingly. Fixes: 0676bfebf576 ("i3c: mipi-i3c-hci: Fix DAT/DCT entry sizes") Signed-off-by: Jarkko Nikula Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 70100fe721840bf6d8e5abd25b8bffe4d2e049b7 Author: Leon Romanovsky Date: Wed Jul 24 13:31:14 2024 +0300 nvme-pci: add missing condition check for existence of mapped data [ Upstream commit c31fad1470389666ac7169fe43aa65bf5b7e2cfd ] nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference. Fixes: 4aedb705437f ("nvme-pci: split metadata handling from nvme_map_data / nvme_unmap_data") Signed-off-by: Leon Romanovsky Reviewed-by: Christoph Hellwig Reviewed-by: Nitesh Shetty Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 7b2384f7ebbf6d8eb7bb276dafd4a3dc2f78131f Author: Georgia Garcia Date: Mon Jun 10 09:51:48 2024 -0300 apparmor: unpack transition table if dfa is not present [ Upstream commit e0ff0cff1f6cdce0aa596aac04129893201c4162 ] Due to a bug in earlier userspaces, a transition table may be present even when the dfa is not. Commit 7572fea31e3e ("apparmor: convert fperm lookup to use accept as an index") made the verification check more rigourous regressing old userspaces with the bug. For compatibility reasons allow the orphaned transition table during unpack and discard. Fixes: 7572fea31e3e ("apparmor: convert fperm lookup to use accept as an index") Signed-off-by: Georgia Garcia Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit ac2d19b9ba6c889528c8ab5762b19b0f25dc3804 Author: Ming Lei Date: Wed Jul 24 22:33:11 2024 +0800 ublk: fix UBLK_CMD_DEL_DEV_ASYNC handling [ Upstream commit 55fbb9a5d64e0e590cad5eacc16c99f2482a008f ] In ublk_ctrl_uring_cmd(), ioctl command NR should be used for matching _IOC_NR(cmd_op). Fix it by adding one private macro, and this way is clean. Fixes: 13fe8e6825e4 ("ublk: add UBLK_CMD_DEL_DEV_ASYNC") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20240724143311.2646330-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 697d7ca75d58193a9f994159f0c040814dce96ae Author: Pavel Begunkov Date: Wed Jul 24 12:16:18 2024 +0100 io_uring: fix io_match_task must_hold [ Upstream commit e142e9cd8891b0c6f277ac2c2c254199a6aa56e3 ] The __must_hold annotation in io_match_task() uses a non existing parameter "req", fix it. Fixes: 6af3f48bf6156 ("io_uring: fix link traversal locking") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3e65ee7709e96507cef3d93291746f2c489f2307.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 58b067d997c61897c7c8154d8398cf49457e07aa Author: Rafael J. Wysocki Date: Thu Jul 18 21:01:14 2024 +0200 thermal: core: Back off when polling thermal zones on errors [ Upstream commit f7c1b0e4ae47e67c6f9af84568a5f4a80638ccd8 ] Commit a8a261774466 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid") introduced a polling mechanism by which the thermal core attampts to get a valid temperature value for thermal zones where the .get_temp() callback returns errors to start with (for example, due to initialization ordering woes). However, this polling is carried out periodically ad infinitum and every iteration of it causes a message to be printed to the kernel log which means a lot of log noise on systems where there are thermal zones that never get ready for some reason. It is also not really useful to continuously poll thermal zones that never respond. To address this, modify the thermal core to increase the delay between consecutive thermal zone temperature checks after every check that fails until it reaches a certain maximum value. At that point, the thermal zone in question will be disabled, but user space will be able to reenable it if it believes that the failure is transient. Also change the code to print messages regarding failed temperature checks to the kernel log only twice, once when the thermal zone's .get_temp() callback returns an error for the first time and once when disabling the given thermal zone. In addition, a dev_crit() message will be printed at that point if the given thermal zone contains a critical trip point to notify the system operator about the situation. Fixes: a8a261774466 ("thermal: core: Call monitor_thermal_zone() if zone temperature is invalid") Link: https://lore.kernel.org/linux-acpi/CAGnHSE=RyPK++UG0-wAtVKgeJxe0uzFYgLxm+RUOKKoQquW=Ow@mail.gmail.com/ Reported-by: Tom Yan Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2962033.e9J7NaK4W3@rjwysocki.net Signed-off-by: Sasha Levin commit 4530d81ef57aa37f383ec1c76f7db560affb76a7 Author: Rafael J. Wysocki Date: Thu Jul 18 21:00:35 2024 +0200 thermal: trip: Split thermal_zone_device_set_mode() [ Upstream commit e5f98896efb3b6350cb6f1c241394966dcbcf240 ] Pull a wrapper around thermal zone .change_mode() callback out of thermal_zone_device_set_mode() because it will be used elsewhere subsequently. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/2206793.irdbgypaU6@rjwysocki.net Stable-dep-of: f7c1b0e4ae47 ("thermal: core: Back off when polling thermal zones on errors") Signed-off-by: Sasha Levin commit d5fe884ce28c5005f8582c35333c195a168f841c Author: Artem Chernyshev Date: Tue Jul 16 15:55:14 2024 +0300 iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en [ Upstream commit 630482ee0653decf9e2482ac6181897eb6cde5b8 ] In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en() dom->sdev is equal to NULL, which leads to null dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9afea57384d4 ("iommu/sprd: Release dma buffer to avoid memory leak") Signed-off-by: Artem Chernyshev Reviewed-by: Chunyan Zhang Link: https://lore.kernel.org/r/20240716125522.3690358-1-artem.chernyshev@red-soft.ru Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 0ac864075fc8b4c687d1913150e183649197f544 Author: Thomas Richter Date: Mon Jul 15 12:07:29 2024 +0200 s390/cpum_cf: Fix endless loop in CF_DIAG event stop [ Upstream commit e6ce1f12d777f6ee22b20e10ae6a771e7e6f44f5 ] Event CF_DIAG reads out complete counter sets using stcctm instruction. This is done at event start time when the process starts execution and at event stop time when the process is removed from the CPU. During removal the difference of each counter in the counter sets is calculated and saved as raw data in the ring buffer. This works fine unless the number of counters in a counter set is zero. This may happen for the extended counter set. This set is machine specific and the size of the counter set can be zero even when extended counter set is authorized for read access. This case is not handled. cfdiag_diffctr() checks authorization of the extended counter set. If true the functions assumes the extended counter set has been saved in a data buffer. However this is not the case, cfdiag_getctrset() does not save a counter set with counter set size of zero. This mismatch causes an endless loop in the counter set readout during event stop handling. The calculation of the difference of the counters in each counter now verifies the size of the counter set is non-zero. A counter set with size zero is skipped. Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Acked-by: Heiko Carstens Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 6a54c9737a843532c0ea1af83ac73860801461a1 Author: Vasily Gorbik Date: Thu Jul 11 15:50:26 2024 +0200 s390/setup: Fix __pa/__va for modules under non-GPL licenses [ Upstream commit e188e5d5ffd01d484b5255b88739fcf67b300223 ] The struct vm_layout contains fields used in __pa/__va calculations. Such fundamental things have to be exported with EXPORT_SYMBOL to avoid breakages of out-of-tree modules under non-GPL licenses. Fixes: 7de0446f0b26 ("s390/boot: Make identity mapping base address explicit") Acked-by: Heiko Carstens Acked-by: Alexander Gordeev Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 7368a86b8a3be5266de3de436547af1142dbc1dd Author: Gerd Bayer Date: Thu Jul 11 15:45:27 2024 +0200 s390/pci: Allow allocation of more than 1 MSI interrupt [ Upstream commit ab42fcb511fd9d241bbab7cc3ca04e34e9fc0666 ] On a PCI adapter that provides up to 8 MSI interrupt sources the s390 implementation of PCI interrupts rejected to accommodate them, although the underlying hardware is able to support that. For MSI-X it is sufficient to allocate a single irq_desc per msi_desc, but for MSI multiple irq descriptors are attached to and controlled by a single msi descriptor. Add the appropriate loops to maintain multiple irq descriptors and tie/untie them to/from the appropriate AIBV bit, if a device driver allocates more than 1 MSI interrupt. Common PCI code passes on requests to allocate a number of interrupt vectors based on the device drivers' demand and the PCI functions' capabilities. However, the root-complex of s390 systems support just a limited number of interrupt vectors per PCI function. Produce a kernel log message to inform about any architecture-specific capping that might be done. With this change, we had a PCI adapter successfully raising interrupts to its device driver via all 8 sources. Fixes: a384c8924a8b ("s390/PCI: Fix single MSI only check") Signed-off-by: Gerd Bayer Reviewed-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 943270570f637066164f0e0e781854234f5288b2 Author: Gerd Bayer Date: Thu Jul 11 15:45:26 2024 +0200 s390/pci: Refactor arch_setup_msi_irqs() [ Upstream commit 5fd11b96b43708f2f6e3964412c301c1bd20ec0f ] Factor out adapter interrupt allocation from arch_setup_msi_irqs() in preparation for enabling registration of multiple MSIs. Code movement only, no change of functionality intended. Signed-off-by: Gerd Bayer Reviewed-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Stable-dep-of: ab42fcb511fd ("s390/pci: Allow allocation of more than 1 MSI interrupt") Signed-off-by: Sasha Levin commit dd296402e681670265aaa2711892eab6ef8f507b Author: ethanwu Date: Thu Jul 11 14:47:56 2024 +0800 ceph: fix incorrect kmalloc size of pagevec mempool [ Upstream commit 03230edb0bd831662a7c08b6fef66b2a9a817774 ] The kmalloc size of pagevec mempool is incorrectly calculated. It misses the size of page pointer and only accounts the number for the array. Fixes: a0102bda5bc0 ("ceph: move sb->wb_pagevec_pool to be a global mempool") Signed-off-by: ethanwu Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 00a60bdabefe0a63f7d5ef78e8ca85977e096583 Author: Anna-Maria Behnsen Date: Tue Jul 16 16:19:19 2024 +0200 timers/migration: Do not rely always on group->parent [ Upstream commit facd40aa5c4699f94014012e4e58414c082f2c01 ] When reading group->parent without holding the group lock it is racy against CPUs coming online the first time and thereby creating another level of the hierarchy. This is not a problem when this value is read once to decide whether to abort a propagation or not. The worst outcome is an unnecessary/early CPU wake up. But it is racy when reading it several times during a single 'action' (like activation, deactivation, checking for remote timer expiry,...) and relying on the consitency of this value without holding the lock. This happens at the moment e.g. in tmigr_inactive_up() which is also calling tmigr_udpate_events(). Code relys on group->parent not to change during this 'action'. Update parent struct member description to explain the above only once. Remove parent pointer checks when they are not mandatory (like update of data->childmask). Remove a warning, which would be nice but the trigger of this warning is not reliable and add expand the data structure member description instead. Expand a comment, why it is safe to rely on parent pointer here (inside hierarchy update). Fixes: 7ee988770326 ("timers: Implement the hierarchical pull model") Reported-by: Borislav Petkov Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20240716-tmigr-fixes-v4-1-757baa7803fe@linutronix.de Signed-off-by: Sasha Levin commit 51be301d29d674ff328dfcf23705851f326f35b3 Author: Dan Carpenter Date: Fri Jul 19 18:53:48 2024 -0500 ASoC: TAS2781: Fix tasdev_load_calibrated_data() [ Upstream commit 92c78222168e9035a9bfb8841c2e56ce23e51f73 ] This function has a reversed if statement so it's either a no-op or it leads to a NULL dereference. Fixes: b195acf5266d ("ASoC: tas2781: Fix wrong loading calibrated data sequence") Signed-off-by: Dan Carpenter Link: https://patch.msgid.link/18a29b68-cc85-4139-b7c7-2514e8409a42@stanley.mountain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1978d917827fadb5fbab21acf24cf99e9b7eea25 Author: Pierre-Louis Bossart Date: Mon Jul 22 10:30:02 2024 +0200 ASoC: Intel: use soc_intel_is_byt_cr() only when IOSF_MBI is reachable [ Upstream commit 9931f7d5d251882a147cc5811060097df43e79f5 ] the Intel kbuild bot reports a link failure when IOSF_MBI is built-in but the Merrifield driver is configured as a module. The soc-intel-quirks.h is included for Merrifield platforms, but IOSF_MBI is not selected for that platform. ld.lld: error: undefined symbol: iosf_mbi_read >>> referenced by atom.c >>> sound/soc/sof/intel/atom.o:(atom_machine_select) in archive vmlinux.a This patch forces the use of the fallback static inline when IOSF_MBI is not reachable. Fixes: 536cfd2f375d ("ASoC: Intel: use common helpers to detect CPUs") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202407160704.zpdhJ8da-lkp@intel.com/ Suggested-by: Takashi Iwai Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Bard Liao Link: https://patch.msgid.link/20240722083002.10800-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 70500f4fce35492d9bf422649410cc488c84fcb7 Author: Michal Wajdeczko Date: Thu Jul 11 21:23:19 2024 +0200 drm/xe/pf: Limit fair VF LMEM provisioning [ Upstream commit bf07ca963d4fd11c88a9d4b058f2bd62e8d46a98 ] Due to the current design of the BO and VRAM manager, any object with XE_BO_FLAG_PINNED flag, which the PF driver uses during VF LMEM provisionining, is created with the TTM_PL_FLAG_CONTIGUOUS flag, which may cause VRAM fragmentation that prevents subsequent allocations of larger objects, like fair VF LMEM provisioning. To avoid such failures, round down fair VF LMEM provisioning size to next power of two size, to compensate what xe_ttm_vram_mgr is doing to achieve contiguous allocations. Fixes: ac6598aed1b3 ("drm/xe/pf: Add support to configure SR-IOV VFs") Signed-off-by: Michal Wajdeczko Reviewed-by: Piotr Piórkowski Reviewed-by: Jonathan Cavitt Link: https://patchwork.freedesktop.org/patch/msgid/20240711192320.1198-2-michal.wajdeczko@intel.com Signed-off-by: Lucas De Marchi (cherry picked from commit 4c3fe5eae46b92e2fd961b19f7779608352e5368) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit fa1c57d10700d00ed7ae516888217db4ee23ae7c Author: Ashutosh Dixit Date: Thu Jul 11 14:12:03 2024 -0700 drm/xe/exec: Fix minor bug related to xe_sync_entry_cleanup [ Upstream commit 408c2f14a5d3d7ac4824b96e52693ab271efb738 ] Increment num_syncs after xe_sync_entry_parse() is successful to ensure the xe_sync_entry_cleanup() logic under "err_syncs" label works correctly. v2: Use the same pattern as that in xe_vm.c (Matt Brost) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Ashutosh Dixit Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20240711211203.3728180-1-ashutosh.dixit@intel.com (cherry picked from commit 43a6faa6d9b5e9139758200a79fe9c8f4aaa0c8d) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit eade3b0867db8034a55884a0ce0959430fe5e2f9 Author: Conor Dooley Date: Wed Jul 17 10:59:49 2024 +0100 spi: spidev: add correct compatible for Rohm BH2228FV [ Upstream commit fc28d1c1fe3b3e2fbc50834c8f73dda72f6af9fc ] When Maxime originally added the BH2228FV to the spidev driver, he spelt it incorrectly - the d should have been a b. Add the correctly spelt compatible to the driver. Although the majority of users of this compatible are abusers, there is at least one board that validly uses the incorrect spelt compatible, so keep it in the driver to avoid breaking the few real users it has. Fixes: 8fad805bdc52 ("spi: spidev: Add Rohm DH2228FV DAC compatible string") Signed-off-by: Conor Dooley Acked-by: Maxime Ripard Link: https://patch.msgid.link/20240717-ventricle-strewn-a7678c509e85@spud Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16f6a58b997634ad2ba10fb0ab88bd6150347cbc Author: Venkata Prasad Potturu Date: Thu Jul 18 11:50:02 2024 +0530 ASoC: sof: amd: fix for firmware reload failure in Vangogh platform [ Upstream commit f2038c12e8133bf4c6bd4d1127a23310d55d9e21 ] Setting ACP ACLK as clock source when ACP enters D0 state causing firmware load failure, as per design clock source should be internal clock. Remove acp_clkmux_sel field so that ACP will use internal clock source when ACP enters into D0 state. Fixes: d0dab6b76a9f ("ASoC: SOF: amd: Add sof support for vangogh platform") Signed-off-by: Venkata Prasad Potturu Link: https://patch.msgid.link/20240718062004.581685-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7988f28990117bc37cec1ef5b50b24966f444997 Author: Curtis Malainey Date: Tue Jul 16 10:40:12 2024 +0200 ASoC: Intel: Fix RT5650 SSP lookup [ Upstream commit 6f6a23d42bdfbbfe1b41a23e2c78319a0cc65db3 ] Commit 8efcd4864652 ("ASoC: Intel: sof_rt5682: use common module for sof_card_private initialization") migrated the pin assignment in the context struct up to soc-acpi-intel-ssp-common.c. This uses a lookup table to see if a device has a amp/codec before assigning the pin. The issue here arises when combination parts that serve both (with 2 ports) are used. sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.3/adl_rt5682_def/SSP0-Codec' CPU: 1 PID: 2079 Comm: udevd Tainted: G U 6.6.36-03391-g744739e00023 #1 3be1a2880a0970f65545a957db7d08ef4b3e2c0d Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.552.0 05/07/2024 Call Trace: dump_stack_lvl+0x69/0xa0 sysfs_warn_dup+0x5b/0x70 sysfs_create_dir_ns+0xb0/0x100 kobject_add_internal+0x133/0x3c0 kobject_add+0x66/0xb0 ? device_add+0x65/0x780 device_add+0x164/0x780 snd_soc_add_pcm_runtimes+0x2fa/0x800 snd_soc_bind_card+0x35e/0xc20 devm_snd_soc_register_card+0x48/0x90 platform_probe+0x7b/0xb0 really_probe+0xf7/0x2a0 ... kobject: kobject_add_internal failed for SSP0-Codec with -EEXIST, don't try to register things with the same name in the same directory. The issue is that the ALC5650 was only defined in the codec table and not the amp table which left the pin unassigned but the dai link was still created by the machine driver. Also patch the suffix filename code for the topology to prevent double suffix names as a result of this change. Fixes: 8efcd4864652 ("ASoC: Intel: sof_rt5682: use common module for sof_card_private initialization") Reviewed-by: Bard Liao Signed-off-by: Curtis Malainey Signed-off-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20240716084012.299257-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e68262dcf45c36e22aa2ef9f28add484263ef6c3 Author: Pierre-Louis Bossart Date: Tue Jul 16 10:45:30 2024 +0200 ASOC: SOF: Intel: hda-loader: only wait for HDaudio IOC for IPC4 devices [ Upstream commit 9ee3f0d8c9999eb1ef2866e86f8d57d996fc0348 ] Multiple users report a regression bisected to commit d5263dbbd8af ("ASoC: SOF: Intel: don't ignore IOC interrupts for non-audio transfers"). The firmware version is the likely suspect, as these users relied on SOF 2.0 while Intel only tested with the 2.2 release. Rather than completely disable the wait_for_completion(), which can help us gather timing information on the different stages of the boot process, the simplest course of action is to just disable it for older IPC versions which are no longer under active development. Closes: https://github.com/thesofproject/linux/issues/5072 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218961 Fixes: d5263dbbd8af ("ASoC: SOF: Intel: don't ignore IOC interrupts for non-audio transfers") Tested-by: Mike Krinkin Tested-by: Todd Brandt Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Link: https://patch.msgid.link/20240716084530.300829-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4c61ee99eb97288f7585ca617a76563bec6cc723 Author: Bart Van Assche Date: Thu Jul 11 15:59:52 2024 -0700 nvme-pci: Fix the instructions for disabling power management [ Upstream commit 92fc2c469eb26060384e9b2cd4cb0cc228aba582 ] pcie_aspm=off tells the kernel not to modify the ASPM configuration. This setting does not guarantee that ASPM (Active State Power Management) is disabled. Hence add pcie_port_pm=off. This disables power management for all PCIe ports. This patch has been tested on a workstation with a Samsung SSD 970 EVO Plus NVMe SSD. Fixes: 4641a8e6e145 ("nvme-pci: add trouble shooting steps for timeouts") Cc: Keith Busch Cc: Christoph Hellwig Cc: Chaitanya Kulkarni Signed-off-by: Bart Van Assche Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 45e03d35229b680b79dfea1103a1f2f07d0b5d75 Author: Steve Wilkins Date: Mon Jul 15 12:13:56 2024 +0100 spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer [ Upstream commit 9cf71eb0faef4bff01df4264841b8465382d7927 ] While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20240715-flammable-provoke-459226d08e70@wendy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 65850e52a7e3b62a8f6840db3ad06b7d9be20363 Author: Steve Wilkins Date: Mon Jul 15 12:13:55 2024 +0100 spi: microchip-core: fix init function not setting the master and motorola modes [ Upstream commit 3a5e76283672efddf47cea39ccfe9f5735cc91d5 ] mchp_corespi_init() reads the CONTROL register, sets the master and motorola bits, but doesn't write the value back to the register. The function also doesn't ensure the controller is disabled at the start, which may present a problem if the controller was used by an earlier boot stage as some settings (including the mode) can only be modified while the controller is disabled. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20240715-designing-thus-05f7c26e1da7@wendy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 263b6c23e1ffd2de58eabc979e37243217a58cc2 Author: Steve Wilkins Date: Mon Jul 15 12:13:54 2024 +0100 spi: microchip-core: only disable SPI controller when register value change requires it [ Upstream commit de9850b5c606b754dd7861678d6e2874b96b04f8 ] Setting up many of the registers for a new SPI transfer involves unconditionally disabling the SPI controller, writing the register value and re-enabling the controller. This is being done for registers even when the value is unchanged and is also done for registers that don't require the controller to be disabled for the change to take effect. Make an effort to detect changes to the register values, and only disables the controller if the new register value is different and disabling the controller is required. This stops the controller being repeated disabled and the bus going tristate before every transfer. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins Co-developed-by: Conor Dooley Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20240715-depict-twirl-7e592eeabaad@wendy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0fe496078394251ab85344c015acdefa2f4bd2a4 Author: Steve Wilkins Date: Mon Jul 15 12:13:53 2024 +0100 spi: microchip-core: defer asserting chip select until just before write to TX FIFO [ Upstream commit 22fd98c107c792e35db7abe45298bc3a29bf4723 ] Setting up many of the registers for a new SPI transfer requires the SPI controller to be disabled after set_cs() has been called to assert the chip select line. However, disabling the controller results in the SCLK and MOSI output pins being tristate, which can cause clock transitions to be seen by a slave device whilst SS is active. To fix this, the CS is only set to inactive inline, whilst setting it active is deferred until all registers are set up and the any controller disables have been completed. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20240715-sanitizer-recant-dd96b7a97048@wendy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1504fb528742d1443d69aec424704c4702abd79c Author: Naga Sureshkumar Relli Date: Mon Jul 15 12:13:52 2024 +0100 spi: microchip-core: fix the issues in the isr [ Upstream commit 502a582b8dd897d9282db47c0911d5320ef2e6b9 ] It is possible for the TXDONE interrupt be raised if the tx FIFO becomes temporarily empty while transmitting, resulting in recursive calls to mchp_corespi_write_fifo() and therefore a garbage message might be transmitted depending on when the interrupt is triggered. Moving all of the tx FIFO writes out of the TXDONE portion of the interrupt handler avoids this problem. Most of rest of the TXDONE portion of the handler is problematic too. Only reading the rx FIFO (and finalising the transfer) when the TXDONE interrupt is raised can cause the transfer to stall, if the final bytes of rx data are not available in the rx FIFO when the final TXDONE interrupt is raised. The transfer should be finalised regardless of which interrupt is raised, provided that all tx data has been set and all rx data received. The first issue was encountered "in the wild", the second is theoretical. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Naga Sureshkumar Relli Signed-off-by: Conor Dooley Link: https://patch.msgid.link/20240715-candied-deforest-585685ef3c8a@wendy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa650d0a0b535b5213d247d890ce88a6f1f2c22e Author: Daniel Baluta Date: Mon Jul 15 18:16:53 2024 +0300 ASoC: SOF: imx8m: Fix DSP control regmap retrieval [ Upstream commit 2634f745eac25a33f032df32cf98fca8538a534a ] According to Documentation/devicetree/bindings/dsp/fsl,dsp.yaml fsl,dsp-ctrl is a phandle to syscon block so we need to use correct function to retrieve it. Currently there is no SOF DSP DTS merged into mainline so there is no need to support the old way of retrieving the dsp control node. Fixes: 9ba23717b292 ("ASoC: SOF: imx8m: Implement DSP start") Signed-off-by: Daniel Baluta Link: https://patch.msgid.link/20240715151653.114751-1-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5c19062372bb6207fb6363996461e0324b25c228 Author: Markus Elfring Date: Tue Jun 4 17:02:15 2024 +0200 auxdisplay: ht16k33: Drop reference after LED registration [ Upstream commit 2ccfe94bc3ac980d2d1df9f7a0b2c6d2137abe55 ] The reference count is bumped by device_get_named_child_node() and never dropped. Since LED APIs do not require it to be bumped by the user, drop the reference after LED registration. [andy: rewritten the commit message and amended the change] Fixes: c223d9c636ed ("auxdisplay: ht16k33: Add LED support") Signed-off-by: Markus Elfring Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 47ff960f0e460f7ab6522de851edc48dcd19b877 Author: Al Viro Date: Thu May 30 23:58:26 2024 -0400 lirc: rc_dev_get_from_fd(): fix file leak [ Upstream commit bba1f6758a9ec90c1adac5dcf78f8a15f1bad65b ] missing fdput() on a failure exit Fixes: 6a9d552483d50 "media: rc: bpf attach/detach requires write permission" # v6.9 Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c8f1f53d13c4471ffa284f13a7259672703734ca Author: Al Viro Date: Thu May 30 23:54:55 2024 -0400 powerpc: fix a file leak in kvm_vcpu_ioctl_enable_cap() [ Upstream commit b4cf5fc01ce83e5c0bcf3dbb9f929428646b9098 ] missing fdput() on one of the failure exits Fixes: eacc56bb9de3e # v5.2 Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 46c17ead5b7389e22e7dc9903fd0ba865d05bda2 Author: Xiao Liang Date: Sat Sep 2 08:48:38 2023 +0800 apparmor: Fix null pointer deref when receiving skb during sock creation [ Upstream commit fce09ea314505a52f2436397608fa0a5d0934fb1 ] The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Fixes: ab9f2115081a ("apparmor: Allow filtering based on secmark policy") Signed-off-by: Xiao Liang Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 7e4a539bca7d8d20f2c5d93c18cce8ef77cd78e0 Author: Dan Carpenter Date: Wed Jul 24 11:08:18 2024 -0500 mISDN: Fix a use after free in hfcmulti_tx() [ Upstream commit 61ab751451f5ebd0b98e02276a44e23a10110402 ] Don't dereference *sp after calling dev_kfree_skb(*sp). Fixes: af69fb3a8ffa ("Add mISDN HFC multiport driver") Signed-off-by: Dan Carpenter Reviewed-by: Simon Horman Link: https://patch.msgid.link/8be65f5a-c2dd-4ba0-8a10-bfe5980b8cfb@stanley.mountain Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 35dd37536e2e082ef3ccae3795dff2ea8ccdb79d Author: Stanislav Fomichev Date: Fri Jul 12 18:52:51 2024 -0700 xsk: Require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata_len [ Upstream commit d5e726d9143c5624135f5dc9e4069799adeef734 ] Julian reports that commit 341ac980eab9 ("xsk: Support tx_metadata_len") can break existing use cases which don't zero-initialize xdp_umem_reg padding. Introduce new XDP_UMEM_TX_METADATA_LEN to make sure we interpret the padding as tx_metadata_len only when being explicitly asked. Fixes: 341ac980eab9 ("xsk: Support tx_metadata_len") Reported-by: Julian Schindel Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Reviewed-by: Maciej Fijalkowski Link: https://lore.kernel.org/bpf/20240713015253.121248-2-sdf@fomichev.me Signed-off-by: Sasha Levin commit ec4eea14d75f7b0491194dd413f540dd19b8c733 Author: Fred Li Date: Fri Jul 19 10:46:53 2024 +0800 bpf: Fix a segment issue when downgrading gso_size [ Upstream commit fa5ef655615a01533035c6139248c5b33aa27028 ] Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2]. Fixes: 2be7e212d5419 ("bpf: add bpf_skb_adjust_room helper") Signed-off-by: Fred Li Signed-off-by: Daniel Borkmann Reviewed-by: Willem de Bruijn Acked-by: Daniel Borkmann Link: https://lore.kernel.org/all/20240626065555.35460-2-dracodingfly@gmail.com [1] Link: https://lore.kernel.org/all/668d5cf1ec330_1c18c32947@willemb.c.googlers.com.notmuch [2] Link: https://lore.kernel.org/bpf/20240719024653.77006-1-dracodingfly@gmail.com Signed-off-by: Sasha Levin commit af6bd5c9901b13a26eaf4d57d97a813297791596 Author: Breno Leitao Date: Wed Jul 24 01:05:23 2024 -0700 net: mediatek: Fix potential NULL pointer dereference in dummy net_device handling [ Upstream commit 16f3a28cf5f876a7f3550d8f4c870a7b41bcfaef ] Move the freeing of the dummy net_device from mtk_free_dev() to mtk_remove(). Previously, if alloc_netdev_dummy() failed in mtk_probe(), eth->dummy_dev would be NULL. The error path would then call mtk_free_dev(), which in turn called free_netdev() assuming dummy_dev was allocated (but it was not), potentially causing a NULL pointer dereference. By moving free_netdev() to mtk_remove(), we ensure it's only called when mtk_probe() has succeeded and dummy_dev is fully allocated. This addresses a potential NULL pointer dereference detected by Smatch[1]. Fixes: b209bd6d0bff ("net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/4160f4e0-cbef-4a22-8b5d-42c4d399e1f7@stanley.mountain/ [1] Suggested-by: Dan Carpenter Reviewed-by: Dan Carpenter Signed-off-by: Breno Leitao Reviewed-by: Simon Horman Link: https://patch.msgid.link/20240724080524.2734499-1-leitao@debian.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a13d3864b76ac87085ec530b2ff8e37482a63a96 Author: Petr Machata Date: Tue Jul 23 18:04:16 2024 +0200 net: nexthop: Initialize all fields in dumped nexthops [ Upstream commit 6d745cd0e9720282cd291d36b9db528aea18add2 ] struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fa938b04359f0f292f0d3ba26f508d8dcbbeb672 Author: Simon Horman Date: Tue Jul 23 14:29:27 2024 +0100 net: stmmac: Correct byte order of perfect_match [ Upstream commit e9dbebae2e3c338122716914fe105458f41e3a4a ] The perfect_match parameter of the update_vlan_hash operation is __le16, and is correctly converted from host byte-order in the lone caller, stmmac_vlan_update(). However, the implementations of this caller, dwxgmac2_update_vlan_hash() and dwxgmac2_update_vlan_hash(), both treat this parameter as host byte order, using the following pattern: u32 value = ... ... writel(value | perfect_match, ...); This is not correct because both: 1) value is host byte order; and 2) writel expects a host byte order value as it's first argument I believe that this will break on big endian systems. And I expect it has gone unnoticed by only being exercised on little endian systems. The approach taken by this patch is to update the callback, and it's caller to simply use a host byte order value. Flagged by Sparse. Compile tested only. Fixes: c7ab0b8088d7 ("net: stmmac: Fallback to VLAN Perfect filtering if HASH is not available") Signed-off-by: Simon Horman Reviewed-by: Maxime Chevallier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dd66c60645ff06b90843f48b450258e62d7c997a Author: Hangbin Liu Date: Tue Jul 23 16:22:52 2024 +0800 selftests: forwarding: skip if kernel not support setting bridge fdb learning limit [ Upstream commit 863ff546fb62a8fa75757a30794ab6ec6cc4bab7 ] If the testing kernel doesn't support setting fdb_max_learned or show fdb_n_learned, just skip it. Or we will get errors like ./bridge_fdb_learning_limit.sh: line 218: [: null: integer expression expected ./bridge_fdb_learning_limit.sh: line 225: [: null: integer expression expected Fixes: 6f84090333bb ("selftests: forwarding: bridge_fdb_learning_limit: Add a new selftest") Signed-off-by: Hangbin Liu Acked-by: Nikolay Aleksandrov Reviewed-by: Johannes Nixdorf Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2abe350db1aa599eeebc6892237d0bce0f1de62a Author: Shigeru Yoshida Date: Tue Jul 16 11:09:05 2024 +0900 tipc: Return non-zero value from tipc_udp_addr2str() on error [ Upstream commit fa96c6baef1b5385e2f0c0677b32b3839e716076 ] tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address. Fixes: d0f91938bede ("tipc: add ip/udp media type") Signed-off-by: Shigeru Yoshida Reviewed-by: Tung Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a939f3f9975b3ce4d3959dad45ba48882cd5ac23 Author: David Howells Date: Fri Jul 19 15:20:18 2024 +0100 netfs: Fix writeback that needs to go to both server and cache [ Upstream commit 212be98aa19303cbf376d61faf9de3ec9997c1cd ] When netfslib is performing writeback (ie. ->writepages), it maintains two parallel streams of writes, one to the server and one to the cache, but it doesn't mark either stream of writes as active until it gets some data that needs to be written to that stream. This is done because some folios will only be written to the cache (e.g. copying to the cache on read is done by marking the folios and letting writeback do the actual work) and sometimes we'll only be writing to the server (e.g. if there's no cache). Now, since we don't actually dispatch uploads and cache writes in parallel, but rather flip between the streams, depending on which has the lowest so-far-issued offset, and don't wait for the subreqs to finish before flipping, we can end up in a situation where, say, we issue a write to the server and this completes before we start the write to the cache. But because we only activate a stream when we first add a subreq to it, the result collection code may run before we manage to activate the stream - resulting in the folio being cleaned and having the writeback-in-progress mark removed. At this point, the folio no longer belongs to us. This is only really a problem for folios that need to be written to both streams - and in that case, the upload to the server is started first, followed by the write to the cache - and the cache write may see a bad folio. Fix this by activating the cache stream up front if there's a cache available. If there's a cache, then all data is going to be written to it. Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Signed-off-by: David Howells Link: https://lore.kernel.org/r/1599053.1721398818@warthog.procyon.org.uk cc: Jeff Layton cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit c8f36af07025c196050e3cb00aa09c5756d53359 Author: Florian Westphal Date: Fri Jul 19 13:19:26 2024 +0200 netfilter: nft_set_pipapo_avx2: disable softinterrupts [ Upstream commit a16909ae9982e931841c456061cb57fbaec9c59e ] We need to disable softinterrupts, else we get following problem: 1. pipapo_avx2 called from process context; fpu usable 2. preempt_disable() called, pcpu scratchmap in use 3. softirq handles rx or tx, we re-enter pipapo_avx2 4. fpu busy, fallback to generic non-avx version 5. fallback reuses scratch map and index, which are in use by the preempted process Handle this same way as generic version by first disabling softinterrupts while the scratchmap is in use. Fixes: f0b3d338064e ("netfilter: nft_set_pipapo_avx2: Add irq_fpu_usable() check, fallback to non-AVX2 version") Cc: Stefano Brivio Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0c69f4777924f3e4e5d8527ea55ee8fedb09028b Author: Wojciech Drewek Date: Mon Jul 1 11:05:46 2024 +0200 ice: Fix recipe read procedure [ Upstream commit 19abb9c2b900bad59e0a9818d6c83bb4cc875437 ] When ice driver reads recipes from firmware information about need_pass_l2 and allow_pass_l2 flags is not stored correctly. Those flags are stored as one bit each in ice_sw_recipe structure. Because of that, the result of checking a flag has to be casted to bool. Note that the need_pass_l2 flag currently works correctly, because it's stored in the first bit. Fixes: bccd9bce29e0 ("ice: Add guard rule when creating FDB in switchdev") Reviewed-by: Marcin Szycik Reviewed-by: Przemek Kitszel Signed-off-by: Wojciech Drewek Reviewed-by: Simon Horman Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b3892898d0ea8a083ee95fe3c882ca29fc4678d2 Author: Johannes Berg Date: Fri Jul 19 09:41:18 2024 -0700 net: bonding: correctly annotate RCU in bond_should_notify_peers() [ Upstream commit 3ba359c0cd6eb5ea772125a7aededb4a2d516684 ] RCU use in bond_should_notify_peers() looks wrong, since it does rcu_dereference(), leaves the critical section, and uses the pointer after that. Luckily, it's called either inside a nested RCU critical section or with the RTNL held. Annotate it with rcu_dereference_rtnl() instead, and remove the inner RCU critical section. Fixes: 4cb4f97b7e36 ("bonding: rebuild the lock use for bond_mii_monitor()") Reviewed-by: Jiri Pirko Signed-off-by: Johannes Berg Acked-by: Jay Vosburgh Link: https://patch.msgid.link/20240719094119.35c62455087d.I68eb9c0f02545b364b79a59f2110f2cf5682a8e2@changeid Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7cdbc23424d7b150ff55d203dbb592d779e08671 Author: Ido Schimmel Date: Thu Jul 18 15:34:07 2024 +0300 ipv4: Fix incorrect source address in Record Route option [ Upstream commit cc73bbab4b1fb8a4f53a24645871dafa5f81266a ] The Record Route IP option records the addresses of the routers that routed the packet. In the case of forwarded packets, the kernel performs a route lookup via fib_lookup() and fills in the preferred source address of the matched route. The lookup is performed with the DS field of the forwarded packet, but using the RT_TOS() macro which only masks one of the two ECN bits. If the packet is ECT(0) or CE, the matched route might be different than the route via which the packet was forwarded as the input path masks both of the ECN bits, resulting in the wrong address being filled in the Record Route option. Fix by masking both of the ECN bits. Fixes: 8e36360ae876 ("ipv4: Remove route key identity dependencies in ip_rt_get_source().") Signed-off-by: Ido Schimmel Reviewed-by: Guillaume Nault Link: https://patch.msgid.link/20240718123407.434778-1-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 44f83b7e45ae8362c1d8442e011d5280972f7dca Author: Gregory CLEMENT Date: Mon Jul 22 15:15:39 2024 +0200 MIPS: SMP-CPS: Fix address for GCR_ACCESS register for CM3 and later [ Upstream commit a263e5f309f32301e1f3ad113293f4e68a82a646 ] When the CM block migrated from CM2.5 to CM3.0, the address offset for the Global CSR Access Privilege register was modified. We saw this in the "MIPS64 I6500 Multiprocessing System Programmer's Guide," it is stated that "the Global CSR Access Privilege register is located at offset 0x0120" in section 5.4. It is at least the same for I6400. This fix allows to use the VP cores in SMP mode if the reset values were modified by the bootloader. Based on the work of Vladimir Kondratiev and the feedback from Jiaxun Yang . Fixes: 197e89e0984a ("MIPS: mips-cm: Implement mips_cm_revision") Signed-off-by: Gregory CLEMENT Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ba61d9ecc604b82de07118ce5c72dbc402c61ab3 Author: Liwei Song Date: Mon Jul 22 16:32:59 2024 +0800 tools/resolve_btfids: Fix comparison of distinct pointer types warning in resolve_btfids [ Upstream commit 13c9b702e6cb8e406d5fa6b2dca422fa42d2f13e ] Add a type cast for set8->pairs to fix below compile warning: main.c: In function 'sets_patch': main.c:699:50: warning: comparison of distinct pointer types lacks a cast 699 | BUILD_BUG_ON(set8->pairs != &set8->pairs[0].id); | ^~ Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h") Signed-off-by: Liwei Song Signed-off-by: Daniel Borkmann Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240722083305.4009723-1-liwei.song.lsong@gmail.com Signed-off-by: Sasha Levin commit 2188279e6b2a35a883dae14c132eeba7590d0d7f Author: Hou Tao Date: Sun Jul 14 14:55:33 2024 +0800 bpf, events: Use prog to emit ksymbol event for main program [ Upstream commit 0be9ae5486cd9e767138c13638820d240713f5f1 ] Since commit 0108a4e9f358 ("bpf: ensure main program has an extable"), prog->aux->func[0]->kallsyms is left as uninitialized. For BPF programs with subprogs, the symbol for the main program is missing just as shown in the output of perf script below: ffffffff81284b69 qp_trie_lookup_elem+0xb9 ([kernel.kallsyms]) ffffffffc0011125 bpf_prog_a4a0eb0651e6af8b_lookup_qp_trie+0x5d (bpf...) ffffffff8127bc2b bpf_for_each_array_elem+0x7b ([kernel.kallsyms]) ffffffffc00110a1 +0x25 () ffffffff8121a89a trace_call_bpf+0xca ([kernel.kallsyms]) Fix it by always using prog instead prog->aux->func[0] to emit ksymbol event for the main program. After the fix, the output of perf script will be correct: ffffffff81284b96 qp_trie_lookup_elem+0xe6 ([kernel.kallsyms]) ffffffffc001382d bpf_prog_a4a0eb0651e6af8b_lookup_qp_trie+0x5d (bpf...) ffffffff8127bc2b bpf_for_each_array_elem+0x7b ([kernel.kallsyms]) ffffffffc0013779 bpf_prog_245c55ab25cfcf40_qp_trie_lookup+0x25 (bpf...) ffffffff8121a89a trace_call_bpf+0xca ([kernel.kallsyms]) Fixes: 0108a4e9f358 ("bpf: ensure main program has an extable") Signed-off-by: Hou Tao Signed-off-by: Daniel Borkmann Tested-by: Yonghong Song Reviewed-by: Krister Johansen Reviewed-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240714065533.1112616-1-houtao@huaweicloud.com Signed-off-by: Sasha Levin commit 22094f5f52e7bc16c5bf9613365049383650b02e Author: Lance Richardson Date: Thu Jul 18 14:38:24 2024 +0000 dma: fix call order in dmam_free_coherent [ Upstream commit 28e8b7406d3a1f5329a03aa25a43aa28e087cb20 ] dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. Tested: kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 Fixes: 9ac7849e35f7 ("devres: device resource management") Signed-off-by: Lance Richardson Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1c939f94571b90c485fec66cc1c9464e89ed9663 Author: Michal Luczaj Date: Sat Jul 13 21:41:38 2024 +0200 af_unix: Disable MSG_OOB handling for sockets in sockmap/sockhash [ Upstream commit 638f32604385fd23059985da8de918e9c18f0b98 ] AF_UNIX socket tracks the most recent OOB packet (in its receive queue) with an `oob_skb` pointer. BPF redirecting does not account for that: when an OOB packet is moved between sockets, `oob_skb` is left outdated. This results in a single skb that may be accessed from two different sockets. Take the easy way out: silently drop MSG_OOB data targeting any socket that is in a sockmap or a sockhash. Note that such silent drop is akin to the fate of redirected skb's scm_fp_list (SCM_RIGHTS, SCM_CREDENTIALS). For symmetry, forbid MSG_OOB in unix_bpf_recvmsg(). Fixes: 314001f0bf92 ("af_unix: Add OOB support") Suggested-by: Kuniyuki Iwashima Signed-off-by: Michal Luczaj Signed-off-by: Daniel Borkmann Tested-by: Jakub Sitnicki Reviewed-by: Kuniyuki Iwashima Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20240713200218.2140950-2-mhal@rbox.co Signed-off-by: Sasha Levin commit 8fa2d3427f98c0ada67bba1134eab56355a696ac Author: Andrii Nakryiko Date: Fri Jul 12 15:44:42 2024 -0700 libbpf: Fix no-args func prototype BTF dumping syntax [ Upstream commit 189f1a976e426011e6a5588f1d3ceedf71fe2965 ] For all these years libbpf's BTF dumper has been emitting not strictly valid syntax for function prototypes that have no input arguments. Instead of `int (*blah)()` we should emit `int (*blah)(void)`. This is not normally a problem, but it manifests when we get kfuncs in vmlinux.h that have no input arguments. Due to compiler internal specifics, we get no BTF information for such kfuncs, if they are not declared with proper `(void)`. The fix is trivial. We also need to adjust a few ancient tests that happily assumed `()` is correct. Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Reported-by: Tejun Heo Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20240712224442.282823-1-andrii@kernel.org Signed-off-by: Sasha Levin commit db35552a6ffeeb63b396aa6297211508544ab3a2 Author: Puranjay Mohan Date: Mon Jul 15 17:33:27 2024 +0000 selftests/bpf: fexit_sleep: Fix stack allocation for arm64 [ Upstream commit e1ef78dce9b7b0fa7f9d88bb3554441d74d33b34 ] On ARM64 the stack pointer should be aligned at a 16 byte boundary or the SPAlignmentFault can occur. The fexit_sleep selftest allocates the stack for the child process as a character array, this is not guaranteed to be aligned at 16 bytes. Because of the SPAlignmentFault, the child process is killed before it can do the nanosleep call and hence fentry_cnt remains as 0. This causes the main thread to hang on the following line: while (READ_ONCE(fexit_skel->bss->fentry_cnt) != 2); Fix this by allocating the stack using mmap() as described in the example in the man page of clone(). Remove the fexit_sleep test from the DENYLIST of arm64. Fixes: eddbe8e65214 ("selftest/bpf: Add a test to check trampoline freeing logic.") Signed-off-by: Puranjay Mohan Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240715173327.8657-1-puranjay@kernel.org Signed-off-by: Sasha Levin commit fce48882dfbc8f764be7c98d856d6b34d580bfc0 Author: Masahiro Yamada Date: Thu Jul 4 22:13:58 2024 +0900 kbuild: avoid build error when single DTB is turned into composite DTB [ Upstream commit 712aba5543b88996bc4682086471076fbf048927 ] As commit afa974b77128 ("kbuild: add real-prereqs shorthand for $(filter-out FORCE,$^)") explained, $(real-prereqs) is not just a list of objects when linking a multi-object module. If a single-object module is turned into a multi-object module, $^ (and therefore $(real-prereqs) as well) contains header files recorded in the *.cmd file. Such headers must be filtered out. Now that a DTB can be built either from a single source or multiple source files, the same issue can occur. Consider the following scenario: First, foo.dtb is implemented as a single-blob device tree. The code looks something like this: [Sample Code 1] Makefile: dtb-y += foo.dtb foo.dts: #include /dts-v1/; / { }; When it is compiled, .foo.dtb.cmd records that foo.dtb depends on scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h. Later, foo.dtb is split into a base and an overlay. The code looks something like this: [Sample Code 2] Makefile: dtb-y += foo.dtb foo-dtbs := foo-base.dtb foo-addon.dtbo foo-base.dts: #include /dts-v1/; / { }; foo-addon.dtso: /dts-v1/; /plugin/; / { }; If you rebuild foo.dtb without 'make clean', you will get this error: Overlay 'scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h' is incomplete $(real-prereqs) contains not only foo-base.dtb and foo-addon.dtbo but also scripts/dtc/include-prefixes/dt-bindings/gpio/gpio.h, which is passed to scripts/dtc/fdtoverlay. Fixes: 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 1cb5934cc096206efd08c0e92d4a189e2507d7e7 Author: Chao Yu Date: Tue Jun 25 10:32:39 2024 +0800 f2fs: fix to update user block counts in block_operations() [ Upstream commit f06c0f82e38bbda7264d6ef3c90045ad2810e0f3 ] Commit 59c9081bc86e ("f2fs: allow write page cache when writting cp") allows write() to write data to page cache during checkpoint, so block count fields like .total_valid_block_count, .alloc_valid_block_count and .rf_node_block_count may encounter race condition as below: CP Thread A - write_checkpoint - block_operations - f2fs_down_write(&sbi->node_change) - __prepare_cp_block : ckpt->valid_block_count = .total_valid_block_count - f2fs_up_write(&sbi->node_change) - write - f2fs_preallocate_blocks - f2fs_map_blocks(,F2FS_GET_BLOCK_PRE_AIO) - f2fs_map_lock - f2fs_down_read(&sbi->node_change) - f2fs_reserve_new_blocks - inc_valid_block_count : percpu_counter_add(&sbi->alloc_valid_block_count, count) : sbi->total_valid_block_count += count - f2fs_up_read(&sbi->node_change) - do_checkpoint : sbi->last_valid_block_count = sbi->total_valid_block_count : percpu_counter_set(&sbi->alloc_valid_block_count, 0) : percpu_counter_set(&sbi->rf_node_block_count, 0) - fsync - need_do_checkpoint - f2fs_space_for_roll_forward : alloc_valid_block_count was reset to zero, so, it may missed last data during checkpoint Let's change to update .total_valid_block_count, .alloc_valid_block_count and .rf_node_block_count in block_operations(), then their access can be protected by .node_change and .cp_rwsem lock, so that it can avoid above race condition. Fixes: 59c9081bc86e ("f2fs: allow write page cache when writting cp") Cc: Yunlei He Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 381cbe85592c78fbaeb3e770e3e9f3bfa3e67efb Author: Daejun Park Date: Thu Jul 4 10:01:21 2024 +0900 f2fs: fix null reference error when checking end of zone [ Upstream commit c82bc1ab2a8a5e73d9728e80c4c2ed87e8921a38 ] This patch fixes a potentially null pointer being accessed by is_end_zone_blkaddr() that checks the last block of a zone when f2fs is mounted as a single device. Fixes: e067dc3c6b9c ("f2fs: maintain six open zones for zoned devices") Signed-off-by: Daejun Park Reviewed-by: Chao Yu Reviewed-by: Daeho Jeong Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e0671f99ae6ef05515ecf6a35aede86d9cd69c4c Author: Claudiu Beznea Date: Fri May 31 09:57:18 2024 +0300 watchdog: rzg2l_wdt: Check return status of pm_runtime_put() [ Upstream commit 471e45a33302852bf79bc140fe418782f50734f6 ] pm_runtime_put() may return an error code. Check its return status. Along with it the rzg2l_wdt_set_timeout() function was updated to propagate the result of rzg2l_wdt_stop() to its caller. Fixes: 2cbc5cd0b55f ("watchdog: Add Watchdog Timer driver for RZ/G2L") Signed-off-by: Claudiu Beznea Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20240531065723.1085423-5-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit a70c141e8fefb84316d7b8eeb0eb87c5c9f4ba7e Author: Claudiu Beznea Date: Fri May 31 09:57:17 2024 +0300 watchdog: rzg2l_wdt: Use pm_runtime_resume_and_get() [ Upstream commit f0ba0fcdd19943809b1a7f760f77f6673c6aa7f7 ] pm_runtime_get_sync() may return with error. In case it returns with error dev->power.usage_count needs to be decremented. pm_runtime_resume_and_get() takes care of this. Thus use it. Along with it the rzg2l_wdt_set_timeout() function was updated to propagate the result of rzg2l_wdt_start() to its caller. Fixes: 2cbc5cd0b55f ("watchdog: Add Watchdog Timer driver for RZ/G2L") Signed-off-by: Claudiu Beznea Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20240531065723.1085423-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 59b0fd36ec2856053608f8fca677c4ff97ca3172 Author: Sheng Yong Date: Mon Jul 8 20:04:07 2024 +0800 f2fs: fix start segno of large section [ Upstream commit 8c409989678e92e4a737e7cd2bb04f3efb81071a ] get_ckpt_valid_blocks() checks valid ckpt blocks in current section. It counts all vblocks from the first to the last segment in the large section. However, START_SEGNO() is used to get the first segno in an SIT block. This patch fixes that to get the correct start segno. Fixes: 61461fc921b7 ("f2fs: fix to avoid touching checkpointed data in get_victim()") Signed-off-by: Sheng Yong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 42b15c72db065766e2425c39648f997698a03dd3 Author: Johannes Berg Date: Wed Jul 3 13:01:45 2024 +0200 um: time-travel: fix signal blocking race/hang [ Upstream commit 2cf3a3c4b84def5406b830452b1cb8bbfffe0ebe ] When signals are hard-blocked in order to do time-travel socket processing, we set signals_blocked and then handle SIGIO signals by setting the SIGIO bit in signals_pending. When unblocking, we first set signals_blocked to 0, and then handle all pending signals. We have to set it first, so that we can again properly block/unblock inside the unblock, if the time-travel handlers need to be processed. Unfortunately, this is racy. We can get into this situation: // signals_pending = SIGIO_MASK unblock_signals_hard() signals_blocked = 0; if (signals_pending && signals_enabled) { block_signals(); unblock_signals() ... sig_handler_common(SIGIO, NULL, NULL); sigio_handler() ... sigio_reg_handler() irq_do_timetravel_handler() reg->timetravel_handler() == vu_req_interrupt_comm_handler() vu_req_read_message() vhost_user_recv_req() vhost_user_recv() vhost_user_recv_header() // reads 12 bytes header of // 20 bytes message <-- receive SIGIO here <-- sig_handler() int enabled = signals_enabled; // 1 if ((signals_blocked || !enabled) && (sig == SIGIO)) { if (!signals_blocked && time_travel_mode == TT_MODE_EXTERNAL) sigio_run_timetravel_handlers() _sigio_handler() sigio_reg_handler() ... as above ... vhost_user_recv_header() // reads 8 bytes that were message payload // as if it were header - but aborts since // it then gets -EAGAIN ... --> end signal handler --> // continue in vhost_user_recv() // full_read() for 8 bytes payload busy loops // entire process hangs here Conceptually, to fix this, we need to ensure that the signal handler cannot run while we hard-unblock signals. The thing that makes this more complex is that we can be doing hard-block/unblock while unblocking. Introduce a new signals_blocked_pending variable that we can keep at non-zero as long as pending signals are being processed, then we only need to ensure it's decremented safely and the signal handler will only increment it if it's already non-zero (or signals_blocked is set, of course.) Note also that only the outermost call to hard-unblock is allowed to decrement signals_blocked_pending, since it could otherwise reach zero in an inner call, and leave the same race happening if the timetravel_handler loops, but that's basically required of it. Fixes: d6b399a0e02a ("um: time-travel/signals: fix ndelay() in interrupt") Link: https://patch.msgid.link/20240703110144.28034-2-johannes@sipsolutions.net Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 336370d5bfbd3264173afc9f179717f20ac7fae5 Author: David Gow Date: Wed May 29 17:33:35 2024 +0800 arch: um: rust: Use the generated target.json again [ Upstream commit 9a2123b397bbe0da5e853273369d63779ac97c8c ] The Rust compiler can take a target config from 'target.json', which is generated by scripts/generate_rust_target.rs. It used to be that all Linux architectures used this to generate a target.json, but now architectures must opt-in to this, or they will default to the Rust compiler's built-in target definition. This is mostly okay for (64-bit) x86 and UML, except that it can generate SSE instructions, which we can't use in the kernel. So re-instate the custom target.json, which disables SSE (and generally enables the 'soft-float' feature). This fixes the following compile error: error: :0:0: in function _RNvMNtCs5QSdWC790r4_4core3f32f7next_up float (float): SSE register return with SSE disabled Fixes: f82811e22b48 ("rust: Refactor the build target to allow the use of builtin targets") Signed-off-by: David Gow Reviewed-by: Boqun Feng Tested-by: Miguel Ojeda Reviewed-by: Miguel Ojeda Link: https://patch.msgid.link/20240529093336.4075206-1-davidgow@google.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a79c2099928e28bae59a663a7940554421ef9161 Author: Johannes Berg Date: Wed Apr 17 10:27:45 2024 +0200 um: time-travel: fix time-travel-start option [ Upstream commit 7d0a8a490aa3a2a82de8826aaf1dfa38575cb77a ] We need to have the = as part of the option so that the value can be parsed properly. Also document that it must be given in nanoseconds, not seconds. Fixes: 065038706f77 ("um: Support time travel mode") Link: https://patch.msgid.link/20240417102744.14b9a9d4eba0.Ib22e9136513126b2099d932650f55f193120cd97@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2025dce49a06f94b45c09cbab6ce47300256bf05 Author: Sean Anderson Date: Fri Jun 28 16:55:36 2024 -0400 phy: zynqmp: Enable reference clock correctly [ Upstream commit 687d6bccb28238fcfa65f7c1badfdfeac498c428 ] Lanes can use other lanes' reference clocks, as determined by refclk. Use refclk to determine the clock to enable/disable instead of always using the lane's own reference clock. This ensures the clock selected in xpsgtr_configure_pll is the one enabled. For the other half of the equation, always program REF_CLK_SEL even when we are selecting the lane's own clock. This ensures that Linux's idea of the reference clock matches the hardware. We use the "local" clock mux for this instead of going through the ref clock network. Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save") Signed-off-by: Sean Anderson Link: https://lore.kernel.org/r/20240628205540.3098010-2-sean.anderson@linux.dev Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 57a05c3a891cb79983e6a0955164698847e0af12 Author: Ma Ke Date: Tue Jul 2 11:20:42 2024 +0800 phy: cadence-torrent: Check return value on register read [ Upstream commit 967969cf594ed3c1678a9918d6e9bb2d1591cbe9 ] cdns_torrent_dp_set_power_state() does not consider that ret might be overwritten. Add return value check of regmap_read_poll_timeout() after register read in cdns_torrent_dp_set_power_state(). Fixes: 5b16a790f18d ("phy: cadence-torrent: Reorder few functions to remove function declarations") Signed-off-by: Ma Ke Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20240702032042.3993031-1-make24@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a1e10962e8dfc3e87835ff2be1496a1e9f57e656 Author: Cristian Ciocaltea Date: Sat Jun 29 03:26:58 2024 +0300 phy: phy-rockchip-samsung-hdptx: Select CONFIG_MFD_SYSCON [ Upstream commit edf9e04955d2387032beac54ebf20b43aaca2adf ] Compile testing configurations without REGMAP support enabled results in a bunch of errors being reported: ../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:569:21: error: variable ‘rk_hdptx_phy_regmap_config’ has initializer but incomplete type 569 | static const struct regmap_config rk_hdptx_phy_regmap_config = { | ^~~~~~~~~~~~~ ../drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c:570:10: error: ‘const struct regmap_config’ has no member named ‘reg_bits’ 570 | .reg_bits = 32, | ^~~~~~~~ Note that selecting REGMAP alone is not enough, because of the following liker error: phy-rockchip-samsung-hdptx.c:(.text+0x10c): undefined reference to `__devm_regmap_init_mmio_clk' Instead of the obvious fix to enable REGMAP_MMIO, select MFD_SYSCON, which implicitly enables REGMAP_MMIO as well. The rationale is that the driver has been already relying on the syscon functionality. Moreover, without MFD_SYSCON enabled, the test coverage is reduced, since the linker might not detect any potential undefined references following syscon_regmap_lookup_by_phandle() invocation in rk_hdptx_phy_probe() body. That is because the function would unconditionally return -ENOTSUP, hence the compiler is free to optimize out any unreachable code. Finally ensure PHY_ROCKCHIP_SAMSUNG_HDPTX depends on HAS_IOMEM, as required by MFD_SYSCON. Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20240629-rk-hdptx-compile-test-fix-v1-1-c86675ba8070@collabora.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2f32c3f818537127a6224e0ed9fa2ccb9bcba25c Author: Vignesh Raghavendra Date: Fri Jun 7 23:41:03 2024 +0530 dmaengine: ti: k3-udma: Fix BCHAN count with UHC and HC channels [ Upstream commit 372f8b3621294173f539b32976e41e6e12f5decf ] Unlike other channel counts in CAPx registers, BCDMA BCHAN CNT doesn't include UHC and HC BC channels. So include them explicitly to arrive at total BC channel in the instance. Fixes: 8844898028d4 ("dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling") Signed-off-by: Vignesh Raghavendra Signed-off-by: Jai Luthra Tested-by: Jayesh Choudhary Link: https://lore.kernel.org/r/20240607-bcdma_chan_cnt-v2-1-bf1a55529d91@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6aa6892a90a5a7fabffe5692ab9f06a7a46c6e42 Author: Jeongjun Park Date: Thu May 30 22:28:09 2024 +0900 jfs: Fix array-index-out-of-bounds in diFree [ Upstream commit f73f969b2eb39ad8056f6c7f3a295fa2f85e313a ] Reported-by: syzbot+241c815bda521982cb49@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jeongjun Park Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 7b27de0d27e41718b34ebe493d9578578a2de720 Author: Douglas Anderson Date: Tue May 28 07:11:48 2024 -0700 kdb: Use the passed prompt in kdb_position_cursor() [ Upstream commit e2e821095949cde46256034975a90f88626a2a73 ] The function kdb_position_cursor() takes in a "prompt" parameter but never uses it. This doesn't _really_ matter since all current callers of the function pass the same value and it's a global variable, but it's a bit ugly. Let's clean it up. Found by code inspection. This patch is expected to functionally be a no-op. Fixes: 09b35989421d ("kdb: Use format-strings rather than '\0' injection in kdb_read()") Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20240528071144.1.I0feb49839c6b6f4f2c4bf34764f5e95de3f55a66@changeid Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit 9711067017a23e5a9d9cffa87b591c8e1f3e80b7 Author: Arnd Bergmann Date: Tue May 28 14:11:48 2024 +0200 kdb: address -Wformat-security warnings [ Upstream commit 70867efacf4370b6c7cdfc7a5b11300e9ef7de64 ] When -Wformat-security is not disabled, using a string pointer as a format causes a warning: kernel/debug/kdb/kdb_io.c: In function 'kdb_read': kernel/debug/kdb/kdb_io.c:365:36: error: format not a string literal and no format arguments [-Werror=format-security] 365 | kdb_printf(kdb_prompt_str); | ^~~~~~~~~~~~~~ kernel/debug/kdb/kdb_io.c: In function 'kdb_getstr': kernel/debug/kdb/kdb_io.c:456:20: error: format not a string literal and no format arguments [-Werror=format-security] 456 | kdb_printf(kdb_prompt_str); | ^~~~~~~~~~~~~~ Use an explcit "%s" format instead. Signed-off-by: Arnd Bergmann Fixes: 5d5314d6795f ("kdb: core for kgdb back end (1 of 2)") Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20240528121154.3662553-1-arnd@kernel.org Signed-off-by: Daniel Thompson Signed-off-by: Sasha Levin commit cda36155fc4583dcc7b1405a9548e2398663eebf Author: Dmitry Baryshkov Date: Fri Jun 14 13:18:24 2024 +0300 phy: qcom: qmp-pcie: restore compatibility with existing DTs [ Upstream commit 912cee11c14376a6f707d72fcaf343a40bff48e8 ] Existing device trees specify only a single clock-output-name for the PCIe PHYs. The function phy_aux_clk_register() expects a second entry in that property. When it doesn't find it, it returns an error, thus failing the probe of the PHY and thus breaking support for the corresponding PCIe host. Follow the approach of the combo USB+DT PHY and generate the name for the AUX clocks instead of requiring it in DT. Fixes: 583ca9ccfa80 ("phy: qcom: qmp-pcie: register second optional PHY AUX clock") Reviewed-by: Neil Armstrong Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240614-fix-pcie-phy-compat-v3-1-730d1811acf4@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3ba0ae885215b325605ff7ebf6de12ac2adf204d Author: Chao Yu Date: Wed May 29 18:01:03 2024 +0800 f2fs: fix to truncate preallocated blocks in f2fs_file_open() [ Upstream commit 298b1e4182d657c3e388adcc29477904e9600ed5 ] chenyuwen reports a f2fs bug as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscrypt_set_bio_crypt_ctx+0x78/0x1e8 f2fs_grab_read_bio+0x78/0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c/0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 do_new_mount+0x298/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60/0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec It is because inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc - f2fs_iget - f2fs_truncate So, let's relocate truncation of preallocated blocks to f2fs_file_open(), after fscrypt_file_open(). Fixes: d4dd19ec1ea0 ("f2fs: do not expose unwritten blocks to user by DIO") Reported-by: chenyuwen Closes: https://lore.kernel.org/linux-kernel/20240517085327.1188515-1-yuwen.chen@xjmz.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 7b4219d0212ad08c75d5d762b638af6e156079a2 Author: Linus Torvalds Date: Sun Jul 28 17:06:20 2024 -0700 minmax: scsi: fix mis-use of 'clamp()' in sr.c commit 9f499b8c791d2983c0a31a543c51d1b2f15e8755 upstream. While working on simplifying the minmax functions, and avoiding excessive macro expansion, it turns out that the sr.c use of the 'clamp()' macro has the arguments the wrong way around. The clamp logic is val = clamp(in, low, high); and it returns the input clamped to the low/high limits. But sr.c ddid speed = clamp(0, speed, 0xffff / 177); which clamps the value '0' to the range '[speed, 0xffff / 177]' and ends up being nonsensical. Happily, I don't think anybody ever cared. Fixes: 9fad9d560af5 ("scsi: sr: Fix unintentional arithmetic wraparound") Cc: Justin Stitt Cc: Kees Cook Cc: Martin K. Petersen Signed-off-by: Linus Torvalds Cc: Wentao Guan Signed-off-by: Greg Kroah-Hartman commit 356270ed4de41ed23be5ac332a56d39f1c073b2e Author: WangYuli Date: Sat Jun 22 12:09:59 2024 +0800 Bluetooth: btusb: Add Realtek RTL8852BE support ID 0x13d3:0x3591 commit 473a89b4ed7fd52a419340f7c540d5c8fc96fc75 upstream. Add the support ID(0x13d3, 0x3591) to usb_device_id table for Realtek RTL8852BE. The device table is as follows: T: Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3591 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Cc: stable@vger.kernel.org Signed-off-by: Wentao Guan Signed-off-by: WangYuli Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Erpeng Xu Signed-off-by: Greg Kroah-Hartman commit 692cca98456d59d15bb95e60a3c6ce1903a3ef3f Author: Hilda Wu Date: Mon Jun 17 17:05:18 2024 +0800 Bluetooth: btusb: Add RTL8852BE device 0489:e125 to device tables commit 295ef07a9dae6182ad4b689aa8c6a7dbba21474c upstream. Add the support ID 0489:e125 to usb_device_id table for Realtek RTL8852B chip. The device info from /sys/kernel/debug/usb/devices as below. T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e125 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Hilda Wu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Erpeng Xu Signed-off-by: Greg Kroah-Hartman commit dd2353f1589993922744d238e1c687678e43591e Author: Ilya Dryomov Date: Tue Jul 23 18:07:59 2024 +0200 rbd: don't assume RBD_LOCK_STATE_LOCKED for exclusive mappings commit 2237ceb71f89837ac47c5dce2aaa2c2b3a337a3c upstream. Every time a watch is reestablished after getting lost, we need to update the cookie which involves quiescing exclusive lock. For this, we transition from RBD_LOCK_STATE_LOCKED to RBD_LOCK_STATE_QUIESCING roughly for the duration of rbd_reacquire_lock() call. If the mapping is exclusive and I/O happens to arrive in this time window, it's failed with EROFS (later translated to EIO) based on the wrong assumption in rbd_img_exclusive_lock() -- "lock got released?" check there stopped making sense with commit a2b1da09793d ("rbd: lock should be quiesced on reacquire"). To make it worse, any such I/O is added to the acquiring list before EROFS is returned and this sets up for violating rbd_lock_del_request() precondition that the request is either on the running list or not on any list at all -- see commit ded080c86b3f ("rbd: don't move requests to the running list on errors"). rbd_lock_del_request() ends up processing these requests as if they were on the running list which screws up quiescing_wait completion counter and ultimately leads to rbd_assert(!completion_done(&rbd_dev->quiescing_wait)); being triggered on the next watch error. Cc: stable@vger.kernel.org # 06ef84c4e9c4: rbd: rename RBD_LOCK_STATE_RELEASING and releasing_wait Cc: stable@vger.kernel.org Fixes: 637cd060537d ("rbd: new exclusive lock wait/wake code") Signed-off-by: Ilya Dryomov Reviewed-by: Dongsheng Yang Signed-off-by: Greg Kroah-Hartman commit a049f7a09d4408d586363587faef013e29d7146d Author: Ilya Dryomov Date: Tue Jul 23 17:54:39 2024 +0200 rbd: rename RBD_LOCK_STATE_RELEASING and releasing_wait commit f5c466a0fdb2d9f3650d2e3911b0735f17ba00cf upstream. ... to RBD_LOCK_STATE_QUIESCING and quiescing_wait to recognize that this state and the associated completion are backing rbd_quiesce_lock(), which isn't specific to releasing the lock. While exclusive lock does get quiesced before it's released, it also gets quiesced before an attempt to update the cookie is made and there the lock is not released as long as ceph_cls_set_cookie() succeeds. Signed-off-by: Ilya Dryomov Reviewed-by: Dongsheng Yang Signed-off-by: Greg Kroah-Hartman commit c600e6de0cd09d74e60dba1f3a93cb7b08d2d608 Author: Dragan Simic Date: Mon Jun 17 22:17:48 2024 +0200 drm/panfrost: Mark simple_ondemand governor as softdep commit 80f4e62730a91572b7fdc657f7bb747e107ae308 upstream. Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Panfrost, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or has forced users to introduce some unnecessary workarounds. [3] For future reference, not having support for the simple_ondemand governor in the initial ramdisk produces errors in the kernel log similar to these below, which were taken from a Pine64 RockPro64: panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq panfrost ff9a0000.gpu: Fatal error during GPU init panfrost: probe of ff9a0000.gpu failed with error -22 Having simple_ondemand marked as a softdep for Panfrost may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [4] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [5] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066 [3] https://forum.pine64.org/showthread.php?tid=15458 [4] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [5] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Diederik de Haas Cc: Furkan Kardame Cc: stable@vger.kernel.org Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Dragan Simic Reviewed-by: Steven Price Reviewed-by: Boris Brezillon Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org Signed-off-by: Greg Kroah-Hartman commit 916dbd422213ca66b7922b6abff18cab2c19acf6 Author: Lucas Stach Date: Fri Jun 21 21:59:19 2024 +0200 drm/etnaviv: don't block scheduler when GPU is still active commit 704d3d60fec451f37706368d9d3e320322978986 upstream. Since 45ecaea73883 ("drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer'") still active jobs aren't put back in the pending list on drm_sched_start(), as they don't have a active parent fence anymore, so if the GPU is still working and the timeout is extended, all currently active jobs will be freed. To avoid prematurely freeing jobs that are still active on the GPU, don't block the scheduler until we are fully committed to actually reset the GPU. As the current job is already removed from the pending list and will not be put back when drm_sched_start() isn't called, we must make sure to put the job back on the pending list when extending the timeout. Cc: stable@vger.kernel.org #6.0 Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 541dbf873533874d3a88460bda741035b62ba50d Author: Jiaxun Yang Date: Fri Jun 14 16:40:14 2024 +0100 MIPS: Loongson64: Test register availability before use commit c04366b1207a036b7de02dfcc1ac7138d3343c9b upstream. Some global register address variable may be missing on specific CPU type, test them before use them. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 8131b5046e70376838138cf7333c6acfaf5b6d8d Author: Jiaxun Yang Date: Fri Jun 14 16:40:16 2024 +0100 MIPS: Loongson64: reset: Prioritise firmware service commit 4e7ca0b57f3bc09ba3e4ab86bf6b7c35134bfd04 upstream. We should always use firmware's poweroff & reboot service if it's available as firmware may need to perform more task than platform's syscon etc. However _machine_restart & poweroff hooks are registered at low priority, which means platform reboot driver can override them. Register firmware based reboot/poweroff implementation with register_sys_off_handler with appropriate priority so that they will be prioritised. Remove _machine_halt hook as it's deemed to be unnecessary. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 82016fa2f209af1497cee38950eab0514ceb7b75 Author: Jiaxun Yang Date: Fri Jun 14 16:40:09 2024 +0100 MIPS: Loongson64: Remove memory node for builtin-dtb commit b81656c37acf1e682dde02f3e07987784b0f3634 upstream. Builtin DTBS should never contain memory node as memory is going to be managed by LEFI interface. Remove memory node to prevent confliction. Fixes: b1a792601f26 ("MIPS: Loongson64: DeviceTree for Loongson-2K1000") Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 519a900ad3e0bc9ca93e80ae3c6a6da411e4df37 Author: Jiaxun Yang Date: Fri Jun 14 16:40:18 2024 +0100 MIPS: Loongson64: env: Hook up Loongsson-2K commit 77543269ff23c75bebfb8e6e9a1177b350908ea7 upstream. Somehow those enablement bits were left over when we were adding initial Loongson-2K support. Set up basic information and select proper builtin DTB for Loongson-2K. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 840db5d790035619b383b45bdd0c7f255fb00ee1 Author: Jiaxun Yang Date: Fri Jun 14 16:40:12 2024 +0100 MIPS: dts: loongson: Fix GMAC phy node commit 813c18d1ca1987afaf47e035152e1baa1375b1b2 upstream. phy-mode should be rgmii-id to match hardware configuration. Also there should be a phy-handle to reference phy node. Fixes: f8a11425075f ("MIPS: Loongson64: Add GMAC support for Loongson-2K1000") Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit b721ae74eb7f98fa1ca0aff27a1478c7220ec074 Author: Jiaxun Yang Date: Sun Jun 16 18:54:24 2024 +0100 MIPS: ip30: ip30-console: Add missing include commit 8de4ed75bd14ed197119ac509c6902a8561e0c1c upstream. Include linux/processor.h to fix build error: arch/mips/sgi-ip30/ip30-console.c: In function ‘prom_putchar’: arch/mips/sgi-ip30/ip30-console.c:21:17: error: implicit declaration of function ‘cpu_relax’ [-Werror=implicit-function-declaration] 21 | cpu_relax(); Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit ed987a5ca77924cb152ce38a880526365f96433b Author: Jiaxun Yang Date: Fri Jun 14 16:40:13 2024 +0100 MIPS: dts: loongson: Add ISA node commit da3f62466e5afc752f8b72146bbc4700dbba5a9f upstream. ISA node is required by Loongson64 platforms to initialize PIO support. Kernel will hang at boot without ISA node. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit e63a9e5475ab262be76d2765a7793c8f632ca710 Author: Aleksandr Mishin Date: Wed Jun 12 16:17:14 2024 +0300 remoteproc: imx_rproc: Fix refcount mistake in imx_rproc_addr_init commit dce68a49be26abf52712e0ee452a45fa01ab4624 upstream. In imx_rproc_addr_init() strcmp() is performed over the node after the of_node_put() is performed over it. Fix this error by moving of_node_put() calls. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Mishin Link: https://lore.kernel.org/r/20240612131714.12907-1-amishin@t-argos.ru Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit c877a5f5268d4ab8224b9c9fbce3d746e4e72bc9 Author: Aleksandr Mishin Date: Thu Jun 6 10:52:04 2024 +0300 remoteproc: imx_rproc: Skip over memory region when node value is NULL commit 2fa26ca8b786888673689ccc9da6094150939982 upstream. In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver") Signed-off-by: Aleksandr Mishin Reviewed-by: Peng Fan Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240606075204.12354-1-amishin@t-argos.ru [Fixed title to fit within the prescribed 70-75 charcters] Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 3a18cb4c711f97af16979f1df8f738f8ff9c1a18 Author: Gwenael Treuveur Date: Tue May 21 18:23:16 2024 +0200 remoteproc: stm32_rproc: Fix mailbox interrupts queuing commit c3281abea67c9c0dc6219bbc41d1feae05a16da3 upstream. Manage interrupt coming from coprocessor also when state is ATTACHED. Fixes: 35bdafda40cc ("remoteproc: stm32_rproc: Add mutex protection for workqueue") Cc: stable@vger.kernel.org Signed-off-by: Gwenael Treuveur Acked-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20240521162316.156259-1-gwenael.treuveur@foss.st.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit ebdee076e6e08fcaefb7d23d452cccb6baf7088e Author: Ilya Dryomov Date: Tue Jul 23 18:08:08 2024 +0200 rbd: don't assume rbd_is_lock_owner() for exclusive mappings commit 3ceccb14f5576e02b81cc8b105ab81f224bd87f6 upstream. Expanding on the previous commit, assuming that rbd_is_lock_owner() always returns true (i.e. that we are either in RBD_LOCK_STATE_LOCKED or RBD_LOCK_STATE_QUIESCING) if the mapping is exclusive is wrong too. In case ceph_cls_set_cookie() fails, the lock would be temporarily released even if the mapping is exclusive, meaning that we can end up even in RBD_LOCK_STATE_UNLOCKED. IOW, exclusive mappings are really "just" about disabling automatic lock transitions (as documented in the man page), not about grabbing the lock and holding on to it whatever it takes. Cc: stable@vger.kernel.org Fixes: 637cd060537d ("rbd: new exclusive lock wait/wake code") Signed-off-by: Ilya Dryomov Reviewed-by: Dongsheng Yang Signed-off-by: Greg Kroah-Hartman commit a59633f6a6aa977e80b4e1f289d6be22209842c1 Author: Eric Biggers Date: Thu Jul 4 16:09:57 2024 +0200 dm-verity: fix dm_is_verity_target() when dm-verity is builtin commit 3708c7269593b836b1d684214cd9f5d83e4ed3fd upstream. When CONFIG_DM_VERITY=y, dm_is_verity_target() returned true for any builtin dm target, not just dm-verity. Fix this by checking for verity_target instead of THIS_MODULE (which is NULL for builtin code). Fixes: b6c1c5745ccc ("dm: Add verity helpers for LoadPin") Cc: stable@vger.kernel.org Cc: Matthias Kaehlcke Cc: Kees Cook Signed-off-by: Eric Biggers Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit 9d8d95b10e614f85e583dae198fc2afd69b8ea3f Author: Michael Ellerman Date: Mon May 20 16:26:47 2024 +1000 selftests/sigaltstack: Fix ppc64 GCC build commit 17c743b9da9e0d073ff19fd5313f521744514939 upstream. Building the sigaltstack test with GCC on 64-bit powerpc errors with: gcc -Wall sas.c -o /home/michael/linux/.build/kselftest/sigaltstack/sas In file included from sas.c:23: current_stack_pointer.h:22:2: error: #error "implement current_stack_pointer equivalent" 22 | #error "implement current_stack_pointer equivalent" | ^~~~~ sas.c: In function ‘my_usr1’: sas.c:50:13: error: ‘sp’ undeclared (first use in this function); did you mean ‘p’? 50 | if (sp < (unsigned long)sstack || | ^~ This happens because GCC doesn't define __ppc__ for 64-bit builds, only 32-bit builds. Instead use __powerpc__ to detect powerpc builds, which is defined by clang and GCC for 64-bit and 32-bit builds. Fixes: 05107edc9101 ("selftests: sigaltstack: fix -Wuninitialized") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Michael Ellerman Link: https://msgid.link/20240520062647.688667-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit bbf2c94503f6a421ed9b79e300d8085810da765d Author: Kim Phillips Date: Tue Jun 4 12:47:39 2024 -0500 crypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked commit 468e3295774d0edce15f4ae475913b5076dd4f40 upstream. Fix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE. Return from __sev_snp_shutdown_locked() if the psp_device or the sev_device structs are not initialized. Without the fix, the driver will produce the following splat: ccp 0000:55:00.5: enabling device (0000 -> 0002) ccp 0000:55:00.5: sev enabled ccp 0000:55:00.5: psp enabled BUG: kernel NULL pointer dereference, address: 00000000000000f0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29 RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0 R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? __die_body+0x6f/0xb0 ? __die+0xcc/0xf0 ? page_fault_oops+0x330/0x3a0 ? save_trace+0x2a5/0x360 ? do_user_addr_fault+0x583/0x630 ? exc_page_fault+0x81/0x120 ? asm_exc_page_fault+0x2b/0x30 ? __sev_snp_shutdown_locked+0x2e/0x150 __sev_firmware_shutdown+0x349/0x5b0 ? pm_runtime_barrier+0x66/0xe0 sev_dev_destroy+0x34/0xb0 psp_dev_destroy+0x27/0x60 sp_destroy+0x39/0x90 sp_pci_remove+0x22/0x60 pci_device_remove+0x4e/0x110 really_probe+0x271/0x4e0 __driver_probe_device+0x8f/0x160 driver_probe_device+0x24/0x120 __driver_attach+0xc7/0x280 ? driver_attach+0x30/0x30 bus_for_each_dev+0x10d/0x130 driver_attach+0x22/0x30 bus_add_driver+0x171/0x2b0 ? unaccepted_memory_init_kdump+0x20/0x20 driver_register+0x67/0x100 __pci_register_driver+0x83/0x90 sp_pci_init+0x22/0x30 sp_mod_init+0x13/0x30 do_one_initcall+0xb8/0x290 ? sched_clock_noinstr+0xd/0x10 ? local_clock_noinstr+0x3e/0x100 ? stack_depot_save_flags+0x21e/0x6a0 ? local_clock+0x1c/0x60 ? stack_depot_save_flags+0x21e/0x6a0 ? sched_clock_noinstr+0xd/0x10 ? local_clock_noinstr+0x3e/0x100 ? __lock_acquire+0xd90/0xe30 ? sched_clock_noinstr+0xd/0x10 ? local_clock_noinstr+0x3e/0x100 ? __create_object+0x66/0x100 ? local_clock+0x1c/0x60 ? __create_object+0x66/0x100 ? parameq+0x1b/0x90 ? parse_one+0x6d/0x1d0 ? parse_args+0xd7/0x1f0 ? do_initcall_level+0x180/0x180 do_initcall_level+0xb0/0x180 do_initcalls+0x60/0xa0 ? kernel_init+0x1f/0x1d0 do_basic_setup+0x41/0x50 kernel_init_freeable+0x1ac/0x230 ? rest_init+0x1f0/0x1f0 kernel_init+0x1f/0x1d0 ? rest_init+0x1f0/0x1f0 ret_from_fork+0x3d/0x50 ? rest_init+0x1f0/0x1f0 ret_from_fork_asm+0x11/0x20 Modules linked in: CR2: 00000000000000f0 ---[ end trace 0000000000000000 ]--- RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0 R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0 PKRU: 55555554 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1fc00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fixes: 1ca5614b84ee ("crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP") Cc: stable@vger.kernel.org Signed-off-by: Kim Phillips Reviewed-by: Liam Merwick Reviewed-by: Mario Limonciello Reviewed-by: John Allen Reviewed-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ee39384ee787e86e9db4efb843818ef0ea9cb8ae Author: Bart Van Assche Date: Wed Jun 5 08:51:01 2024 -0600 RDMA/iwcm: Fix a use-after-free related to destroying CM IDs commit aee2424246f9f1dadc33faa78990c1e2eb7826e4 upstream. iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler; rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished. Cc: stable@vger.kernel.org Fixes: 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") Reviewed-by: Zhu Yanjun Tested-by: Shin'ichiro Kawasaki Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20240605145117.397751-6-bvanassche@acm.org Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 378a9d51afc17c9db7a0d5280228361d65ce9b28 Author: Jiaxun Yang Date: Fri Jun 14 16:40:15 2024 +0100 platform: mips: cpu_hwmon: Disable driver on unsupported hardware commit f4d430db17b4ef4e9c3c352a04b2fe3c93011978 upstream. cpu_hwmon is unsupported on CPUs without loongson_chiptemp register and csr. Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 774ffcb28cd963c1a05b62e861599955a94a57d4 Author: Peter Ujfalusi Date: Mon Jun 24 14:15:18 2024 +0200 ASoC: SOF: ipc4-topology: Use correct queue_id for requesting input pin format commit fe836c78ef1ff16da32912c22348091a0d67bda1 upstream. It is incorrect to request the input pin format of the destination widget using the output pin index of the source module as the indexes are not necessarily matching. moduleA.out_pin1 can be connected to moduleB.in_pin0 for example. Use the dst_queue_id to request the input format of the destination module. This bug remained unnoticed likely because in nocodec topologies we don't have process modules after a module copier, thus the pin/queue index is ignored. For the process module case, the code was likely have been tested in a controlled way where all the pin/queue/format properties were present to work. Update the debug prints to have better information. Reviewed-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Cc: stable@vger.kernel.org # v6.8+ Link: https://patch.msgid.link/20240624121519.91703-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 60609323f13288b4d39d96080c3c58d06a43ccef Author: Krzysztof Kozlowski Date: Mon Jul 1 14:26:16 2024 +0200 ASoC: codecs: wcd939x: Fix typec mux and switch leak during device removal commit 9f3ae72c5dbca9ba558c752f1ef969ed6908be01 upstream. Driver does not unregister typec structures (typec_mux_dev and typec_switch_desc) during removal leading to leaks. Fix this by moving typec registering parts to separate function and using devm interface to release them. This also makes code a bit simpler: - Smaller probe() function with less error paths and no #ifdefs, - No need to store typec_mux_dev and typec_switch_desc in driver state container structure. Cc: stable@vger.kernel.org Fixes: 10f514bd172a ("ASoC: codecs: Add WCD939x Codec driver") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Neil Armstrong Link: https://patch.msgid.link/20240701122616.414158-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9aa5b0f19cc883044582d2c332615ecec465d9af Author: Manivannan Sadhasivam Date: Mon Jun 3 22:13:54 2024 +0530 bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone commit c7d0b2db5bc5e8c0fdc67b3c8f463c3dfec92f77 upstream. MHI endpoint stack accidentally started allocating memory for objects from DMA zone since commit 62210a26cd4f ("bus: mhi: ep: Use slab allocator where applicable"). But there is no real need to allocate memory from this naturally limited DMA zone. This also causes the MHI endpoint stack to run out of memory while doing high bandwidth transfers. So let's switch over to normal memory. Cc: # 6.8 Fixes: 62210a26cd4f ("bus: mhi: ep: Use slab allocator where applicable") Reviewed-by: Mayank Rana Link: https://lore.kernel.org/r/20240603164354.79035-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Greg Kroah-Hartman commit 1bbbaddb25cd72e517d80839fa1216c57967071c Author: Thomas Gleixner Date: Thu Jul 11 22:25:21 2024 +0200 watchdog/perf: properly initialize the turbo mode timestamp and rearm counter commit f944ffcbc2e1c759764850261670586ddf3bdabb upstream. For systems on which the performance counter can expire early due to turbo modes the watchdog handler has a safety net in place which validates that since the last watchdog event there has at least 4/5th of the watchdog period elapsed. This works reliably only after the first watchdog event because the per CPU variable which holds the timestamp of the last event is never initialized. So a first spurious event will validate against a timestamp of 0 which results in a delta which is likely to be way over the 4/5 threshold of the period. As this might happen before the first watchdog hrtimer event increments the watchdog counter, this can lead to false positives. Fix this by initializing the timestamp before enabling the hardware event. Reset the rearm counter as well, as that might be non zero after the watchdog was disabled and reenabled. Link: https://lkml.kernel.org/r/87frsfu15a.ffs@tglx Fixes: 7edaeb6841df ("kernel/watchdog: Prevent false positives with turbo modes") Signed-off-by: Thomas Gleixner Cc: Arjan van de Ven Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 5570209a6551b50f67e26941229eafed6a04cdce Author: Joy Chakraborty Date: Thu Jun 13 12:07:50 2024 +0000 rtc: abx80x: Fix return value of nvmem callback on read commit fc82336b50e7652530bc32caec80be0f8792513b upstream. Read callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. abx80x_nvmem_xfer() on read calls i2c_smbus_read_i2c_block_data() which returns the number of bytes read on success as per its api description, this return value is handled as an error and returned to nvmem even on success. Fix to handle all possible values that would be returned by i2c_smbus_read_i2c_block_data(). Fixes: e90ff8ede777 ("rtc: abx80x: Add nvmem support") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty Reviewed-by: Dan Carpenter Reviewed-by: Sean Anderson Link: https://lore.kernel.org/r/20240613120750.1455209-1-joychakr@google.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit c30b42b558880829b7a8d91aebdcfbca436501d2 Author: Joy Chakraborty Date: Wed Jun 12 08:08:31 2024 +0000 rtc: isl1208: Fix return value of nvmem callbacks commit 70f1ae5f0e7f44edf842444044615da7b59838c1 upstream. Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. isl1208_nvmem_read()/isl1208_nvmem_write() currently return the number of bytes read/written on success, fix to return 0 on success and negative on failure. Fixes: c3544f6f51ed ("rtc: isl1208: Add new style nvmem support to driver") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty Link: https://lore.kernel.org/r/20240612080831.1227131-1-joychakr@google.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 10a93cc4ec9a96e8e08f950c13f32604000bb685 Author: Imre Deak Date: Mon Jul 8 22:00:25 2024 +0300 drm/i915/dp: Don't switch the LTTPR mode on an active link commit 509580fad7323b6a5da27e8365cd488f3b57210e upstream. Switching to transparent mode leads to a loss of link synchronization, so prevent doing this on an active link. This happened at least on an Intel N100 system / DELL UD22 dock, the LTTPR residing either on the host or the dock. To fix the issue, keep the current mode on an active link, adjusting the LTTPR count accordingly (resetting it to 0 in transparent mode). v2: Adjust code comment during link training about reiniting the LTTPRs. (Ville) Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: # v5.15+ Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Reviewed-by: Ankit Nautiyal Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-3-imre.deak@intel.com (cherry picked from commit 211ad49cf8ccfdc798a719b4d1e000d0a8a9e588) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 7d6971bfe1df3f87b525d23ec4a83093b1fb1ff1 Author: Imre Deak Date: Mon Jul 8 22:00:24 2024 +0300 drm/i915/dp: Reset intel_dp->link_trained before retraining the link commit d13e2a6e95e6b87f571c837c71a3d05691def9bb upstream. Regularly retraining a link during an atomic commit happens with the given pipe/link already disabled and hence intel_dp->link_trained being false. Ensure this also for retraining a DP SST link via direct calls to the link training functions (vs. an actual commit as for DP MST). So far nothing depended on this, however the next patch will depend on link_trained==false for changing the LTTPR mode to non-transparent. Cc: # v5.15+ Cc: Ville Syrjälä Reviewed-by: Ankit Nautiyal Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-2-imre.deak@intel.com (cherry picked from commit a4d5ce61765c08ab364aa4b327f6739b646e6cfa) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 9f33d44ab5ef592f2b4175d7fc87dc44291e2832 Author: Ma Ke Date: Thu Jul 18 22:17:35 2024 +0800 drm/amd/amdgpu: Fix uninitialized variable warnings commit df65aabef3c0327c23b840ab5520150df4db6b5f upstream. Return 0 to avoid returning an uninitialized variable r. Cc: stable@vger.kernel.org Fixes: 230dd6bb6117 ("drm/amd/amdgpu: implement mode2 reset on smu_v13_0_10") Signed-off-by: Ma Ke Signed-off-by: Alex Deucher (cherry picked from commit 6472de66c0aa18d50a4b5ca85f8272e88a737676) Signed-off-by: Greg Kroah-Hartman commit 9bf1a4e3d4be4c84475bc97e7e5300d7e06541be Author: Tim Huang Date: Tue Jul 23 16:54:34 2024 +0800 drm/amdgpu: add missed harvest check for VCN IP v4/v5 commit fab1ead0ae3a4757afb92ff6909b37d63db17e55 upstream. To prevent below probe failure, add a check for models with VCN IP v4.0.6 where VCN1 may be harvested. v2: Apply the same check to VCN IP v4.0 and v5.0. [ 54.070117] RIP: 0010:vcn_v4_0_5_start_dpg_mode+0x9be/0x36b0 [amdgpu] [ 54.071055] Code: 80 fb ff 8d 82 00 80 fe ff 81 fe 00 06 00 00 0f 43 c2 49 69 d5 38 0d 00 00 48 8d 71 04 c1 e8 02 4c 01 f2 48 89 b2 50 f6 02 00 <89> 01 48 8b 82 50 f6 02 00 48 8d 48 04 48 89 8a 50 f6 02 00 c7 00 [ 54.072408] RSP: 0018:ffffb17985f736f8 EFLAGS: 00010286 [ 54.072793] RAX: 00000000000000d6 RBX: ffff99a82f680000 RCX: 0000000000000000 [ 54.073315] RDX: ffff99a82f680000 RSI: 0000000000000004 RDI: ffff99a82f680000 [ 54.073835] RBP: ffffb17985f73730 R08: 0000000000000001 R09: 0000000000000000 [ 54.074353] R10: 0000000000000008 R11: ffffb17983c05000 R12: 0000000000000000 [ 54.074879] R13: 0000000000000000 R14: ffff99a82f680000 R15: 0000000000000001 [ 54.075400] FS: 00007f8d9c79a000(0000) GS:ffff99ab2f140000(0000) knlGS:0000000000000000 [ 54.075988] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 54.076408] CR2: 0000000000000000 CR3: 0000000140c3a000 CR4: 0000000000750ef0 [ 54.076927] PKRU: 55555554 [ 54.077132] Call Trace: [ 54.077319] [ 54.077484] ? show_regs+0x69/0x80 [ 54.077747] ? __die+0x28/0x70 [ 54.077979] ? page_fault_oops+0x180/0x4b0 [ 54.078286] ? do_user_addr_fault+0x2d2/0x680 [ 54.078610] ? exc_page_fault+0x84/0x190 [ 54.078910] ? asm_exc_page_fault+0x2b/0x30 [ 54.079224] ? vcn_v4_0_5_start_dpg_mode+0x9be/0x36b0 [amdgpu] [ 54.079941] ? vcn_v4_0_5_start_dpg_mode+0xe6/0x36b0 [amdgpu] [ 54.080617] vcn_v4_0_5_set_powergating_state+0x82/0x19b0 [amdgpu] [ 54.081316] amdgpu_device_ip_set_powergating_state+0x64/0xc0 [amdgpu] [ 54.082057] amdgpu_vcn_ring_begin_use+0x6f/0x1d0 [amdgpu] [ 54.082727] amdgpu_ring_alloc+0x44/0x70 [amdgpu] [ 54.083351] amdgpu_vcn_dec_sw_ring_test_ring+0x40/0x110 [amdgpu] [ 54.084054] amdgpu_ring_test_helper+0x22/0x90 [amdgpu] [ 54.084698] vcn_v4_0_5_hw_init+0x87/0xc0 [amdgpu] [ 54.085307] amdgpu_device_init+0x1f96/0x2780 [amdgpu] [ 54.085951] amdgpu_driver_load_kms+0x1e/0xc0 [amdgpu] [ 54.086591] amdgpu_pci_probe+0x19f/0x550 [amdgpu] [ 54.087215] local_pci_probe+0x48/0xa0 [ 54.087509] pci_device_probe+0xc9/0x250 [ 54.087812] really_probe+0x1a4/0x3f0 [ 54.088101] __driver_probe_device+0x7d/0x170 [ 54.088443] driver_probe_device+0x24/0xa0 [ 54.088765] __driver_attach+0xdd/0x1d0 [ 54.089068] ? __pfx___driver_attach+0x10/0x10 [ 54.089417] bus_for_each_dev+0x8e/0xe0 [ 54.089718] driver_attach+0x22/0x30 [ 54.090000] bus_add_driver+0x120/0x220 [ 54.090303] driver_register+0x62/0x120 [ 54.090606] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [ 54.091255] __pci_register_driver+0x62/0x70 [ 54.091593] amdgpu_init+0x67/0xff0 [amdgpu] [ 54.092190] do_one_initcall+0x5f/0x330 [ 54.092495] do_init_module+0x68/0x240 [ 54.092794] load_module+0x201c/0x2110 [ 54.093093] init_module_from_file+0x97/0xd0 [ 54.093428] ? init_module_from_file+0x97/0xd0 [ 54.093777] idempotent_init_module+0x11c/0x2a0 [ 54.094134] __x64_sys_finit_module+0x64/0xc0 [ 54.094476] do_syscall_64+0x58/0x120 [ 54.094767] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Signed-off-by: Tim Huang Reviewed-by: Saleemkhan Jamadar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org (cherry picked from commit 0b071245ddd98539d4f7493bdd188417fcf2d629) Signed-off-by: Greg Kroah-Hartman commit fa717750ecf1847eb743f33265f40abf42b287ee Author: ZhenGuo Yin Date: Fri Jul 19 16:10:40 2024 +0800 drm/amdgpu: reset vm state machine after gpu reset(vram lost) commit 5659b0c93a1ea02c662a030b322093203f299185 upstream. [Why] Page table of compute VM in the VRAM will lost after gpu reset. VRAM won't be restored since compute VM has no shadows. [How] Use higher 32-bit of vm->generation to record a vram_lost_counter. Reset the VM state machine when vm->genertaion is not equal to the new generation token. v2: Check vm->generation instead of calling drm_sched_entity_error in amdgpu_vm_validate. v3: Use new generation token instead of vram_lost_counter for check. Signed-off-by: ZhenGuo Yin Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org (cherry picked from commit 47c0388b0589cb481c294dcb857d25a214c46eb3) Signed-off-by: Greg Kroah-Hartman commit 972dd51f1857b1da0aeedcfbe4a32e9aea743542 Author: Wayne Lin Date: Wed Jun 26 16:48:23 2024 +0800 drm/dp_mst: Fix all mstb marked as not probed after suspend/resume commit d63d81094d208abb20fc444514b2d9ec2f4b7c4e upstream. [Why] After supend/resume, with topology unchanged, observe that link_address_sent of all mstb are marked as false even the topology probing is done without any error. It is caused by wrongly also include "ret == 0" case as a probing failure case. [How] Remove inappropriate checking conditions. Cc: Lyude Paul Cc: Harry Wentland Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: stable@vger.kernel.org Fixes: 37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit") Signed-off-by: Wayne Lin Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-2-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman commit 60887a89986f0b762e0916acd55068d525ff63fb Author: Thomas Zimmermann Date: Fri May 10 17:47:08 2024 +0200 drm/udl: Remove DRM_CONNECTOR_POLL_HPD commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream. DisplayLink devices do not generate hotplug events. Remove the poll flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT. Signed-off-by: Thomas Zimmermann Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection") Reviewed-by: Jani Nikula Cc: Robert Tarasov Cc: Alex Deucher Cc: Dave Airlie Cc: Sean Paul Cc: Thomas Zimmermann Cc: dri-devel@lists.freedesktop.org Cc: # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20240510154841.11370-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 09a67694edd1f787c206cd2fd066b0ca37debe9f Author: Alex Deucher Date: Tue Jul 9 17:54:11 2024 -0400 drm/amdgpu/sdma5.2: Update wptr registers as well as doorbell commit a03ebf116303e5d13ba9a2b65726b106cb1e96f6 upstream. We seem to have a case where SDMA will sometimes miss a doorbell if GFX is entering the powergating state when the doorbell comes in. To workaround this, we can update the wptr via MMIO, however, this is only safe because we disallow gfxoff in begin_ring() for SDMA 5.2 and then allow it again in end_ring(). Enable this workaround while we are root causing the issue with the HW team. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/3440 Tested-by: Friedrich Vock Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org (cherry picked from commit f2ac52634963fc38e4935e11077b6f7854e5d700) Signed-off-by: Greg Kroah-Hartman commit 1a802eaa152b8380070a65e1e11710d880a99291 Author: Nitin Gote Date: Thu Jul 11 22:02:08 2024 +0530 drm/i915/gt: Do not consider preemption during execlists_dequeue for gen8 commit 65564157ae64cec0f527583f96e32f484f730f92 upstream. We're seeing a GPU hang issue on a CHV platform, which was caused by commit bac24f59f454 ("drm/i915/execlists: Enable coarse preemption boundaries for Gen8"). The Gen8 platform only supports timeslicing and doesn't have a preemption mechanism, as its engines do not have a preemption timer. Commit 751f82b353a6 ("drm/i915/gt: Only disable preemption on Gen8 render engines") addressed this issue only for render engines. This patch extends that fix by ensuring that preemption is not considered for all engines on Gen8 platforms. v4: - Use the correct Fixes tag (Rodrigo Vivi) - Reworded commit log (Andi Shyti) v3: - Inside need_preempt(), condition of can_preempt() is not required as simplified can_preempt() is enough. (Chris Wilson) v2: Simplify can_preempt() function (Tvrtko Ursulin) Fixes: 751f82b353a6 ("drm/i915/gt: Only disable preemption on gen8 render engines") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11396 Suggested-by: Andi Shyti Signed-off-by: Nitin Gote Cc: Chris Wilson CC: # v5.12+ Reviewed-by: Jonathan Cavitt Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti Link: https://patchwork.freedesktop.org/patch/msgid/20240711163208.1355736-1-nitin.r.gote@intel.com (cherry picked from commit 7df0be6e6280c6fca01d039864bb123e5e36604b) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit a9e7274166a7027e018c61fdc2bef6225a03f5e8 Author: Adrian Hunter Date: Mon Jun 24 23:10:56 2024 +0300 perf/x86/intel/pt: Fix a topa_entry base address calculation commit ad97196379d0b8cb24ef3d5006978a6554e6467f upstream. topa_entry->base is a bit-field. Bit-fields are not promoted to a 64-bit type, even if the underlying type is 64-bit, and so, if necessary, must be cast to a larger type when calculations are done. Fix a topa_entry->base address calculation by adding a cast. Without the cast, the address was limited to 36-bits i.e. 64GiB. The address calculation is used on systems that do not support Multiple Entry ToPA (only Broadwell), and affects physical addresses on or above 64GiB. Instead of writing to the correct address, the address comprising the first 36 bits would be written to. Intel PT snapshot and sampling modes are not affected. Fixes: 52ca9ced3f70 ("perf/x86/intel/pt: Add Intel PT PMU driver") Reported-by: Dave Hansen Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240624201101.60186-3-adrian.hunter@intel.com Signed-off-by: Greg Kroah-Hartman commit 9e00108f122c02384d10fd6a25f0d0fb5666bba5 Author: Marco Cavenati Date: Mon Jun 24 23:10:55 2024 +0300 perf/x86/intel/pt: Fix topa_entry base length commit 5638bd722a44bbe97c1a7b3fae5b9efddb3e70ff upstream. topa_entry->base needs to store a pfn. It obviously needs to be large enough to store the largest possible x86 pfn which is MAXPHYADDR-PAGE_SIZE (52-12). So it is 4 bits too small. Increase the size of topa_entry->base from 36 bits to 40 bits. Note, systems where physical addresses can be 256TiB or more are affected. [ Adrian: Amend commit message as suggested by Dave Hansen ] Fixes: 52ca9ced3f70 ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by: Marco Cavenati Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240624201101.60186-2-adrian.hunter@intel.com Signed-off-by: Greg Kroah-Hartman commit 97ad12b9b6e69ec1f65d4d9daafb0f6151b7c04d Author: Kan Liang Date: Mon Jul 8 12:33:36 2024 -0700 perf/x86/intel/ds: Fix non 0 retire latency on Raptorlake commit e5f32ad56b22ebe384a6e7ddad6e9520c5495563 upstream. A non-0 retire latency can be observed on a Raptorlake which doesn't support the retire latency feature. By design, the retire latency shares the PERF_SAMPLE_WEIGHT_STRUCT sample type with other types of latency. That could avoid adding too many different sample types to support all kinds of latency. For the machine which doesn't support some kind of latency, 0 should be returned. Perf doesn’t clear/init all the fields of a sample data for the sake of performance. It expects the later perf_{prepare,output}_sample() to update the uninitialized field. However, the current implementation doesn't touch the field of the retire latency if the feature is not supported. The memory garbage is dumped into the perf data. Clear the retire latency if the feature is not supported. Fixes: c87a31093c70 ("perf/x86: Support Retire Latency") Reported-by: "Bayduraev, Alexey V" Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: "Bayduraev, Alexey V" Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240708193336.1192217-4-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit cfb00bcd6153318564272f52e4c1c08a84420bbd Author: Kan Liang Date: Mon Jul 8 11:55:24 2024 -0700 perf/x86/intel/uncore: Fix the bits of the CHA extended umask for SPR commit a5a6ff3d639d088d4af7e2935e1ee0d8b4e817d4 upstream. The perf stat errors out with UNC_CHA_TOR_INSERTS.IA_HIT_CXL_ACC_LOCAL event. $perf stat -e uncore_cha_55/event=0x35,umask=0x10c0008101/ -a -- ls event syntax error: '..0x35,umask=0x10c0008101/' \___ Bad event or PMU The definition of the CHA umask is config:8-15,32-55, which is 32bit. However, the umask of the event is bigger than 32bit. This is an error in the original uncore spec. Add a new umask_ext5 for the new CHA umask range. Fixes: 949b11381f81 ("perf/x86/intel/uncore: Add Sapphire Rapids server CHA support") Closes: https://lore.kernel.org/linux-perf-users/alpine.LRH.2.20.2401300733310.11354@Diego/ Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ian Rogers Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240708185524.1185505-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3293f2dd0921b9fc35eaae010280d74e9f4d85a5 Author: Kan Liang Date: Thu Jun 6 11:03:16 2024 -0700 perf stat: Fix the hard-coded metrics calculation on the hybrid commit 3612ca8e2935c4c142d99e33b8effa7045ce32b5 upstream. The hard-coded metrics is wrongly calculated on the hybrid machine. $ perf stat -e cycles,instructions -a sleep 1 Performance counter stats for 'system wide': 18,205,487 cpu_atom/cycles/ 9,733,603 cpu_core/cycles/ 9,423,111 cpu_atom/instructions/ # 0.52 insn per cycle 4,268,965 cpu_core/instructions/ # 0.23 insn per cycle The insn per cycle for cpu_core should be 4,268,965 / 9,733,603 = 0.44. When finding the metric events, the find_stat() doesn't take the PMU type into account. The cpu_atom/cycles/ is wrongly used to calculate the IPC of the cpu_core. In the hard-coded metrics, the events from a different PMU are only SW_CPU_CLOCK and SW_TASK_CLOCK. They both have the stat type, STAT_NSECS. Except the SW CLOCK events, check the PMU type as well. Fixes: 0a57b910807a ("perf stat: Use counts rather than saved_value") Reported-by: Khalil, Amiri Reviewed-by: Ian Rogers Signed-off-by: Kan Liang Acked-by: Namhyung Kim Cc: stable@vger.kernel.org Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240606180316.4122904-1-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f34d8307a73a18de5320fcc6f40403146d061891 Author: Frederic Weisbecker Date: Fri Jun 21 11:16:01 2024 +0200 perf: Fix event leak upon exec and file release commit 3a5465418f5fd970e86a86c7f4075be262682840 upstream. The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> perf_pending_irq() //do nothing, rely on pending task work <======= begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed. Fixes: 517e6a301f34 ("perf: Fix perf_pending_task() UaF") Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-5-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3d7a63352a93bdb8a1cdf29606bf617d3ac1c22a Author: Frederic Weisbecker Date: Fri Jun 21 11:16:00 2024 +0200 perf: Fix event leak upon exit commit 2fd5ad3f310de22836cdacae919dd99d758a1f1b upstream. When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] perf_pending_irq() // early return: event->oncpu = -1 [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling. Fixes: 517e6a301f34 ("perf: Fix perf_pending_task() UaF") Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-4-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3eac973eb5cb2b874b3918f924798afc5affd46b Author: Nilesh Javali Date: Wed Jul 10 22:40:48 2024 +0530 scsi: qla2xxx: validate nvme_local_port correctly commit eb1d4ce2609584eeb7694866f34d4b213caa3af9 upstream. The driver load failed with error message, qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef and with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port. Cc: stable@vger.kernel.org Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-3-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 36fdc5319c4d0ec8b8938ec4769764098a246bfb Author: Shreyas Deodhar Date: Wed Jul 10 22:40:52 2024 +0530 scsi: qla2xxx: Complete command early within lock commit 4475afa2646d3fec176fc4d011d3879b26cb26e3 upstream. A crash was observed while performing NPIV and FW reset, BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx] The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARN_ON condition of performing dma_free_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash. Hence complete the command early in unload path but within the lock to avoid race condition. Fixes: 0367076b0817 ("scsi: qla2xxx: Perform lockless command completion in abort path") Cc: stable@vger.kernel.org Signed-off-by: Shreyas Deodhar Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-7-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1e6aca8f07f1e30f1ac10ae44807ba55463ceedd Author: Quinn Tran Date: Wed Jul 10 22:40:51 2024 +0530 scsi: qla2xxx: Fix flash read failure commit 29e222085d8907ccff18ecd931bdd4c6b1f11b92 upstream. Link up failure is observed as a result of flash read failure. Current code does not check flash read return code where it relies on FW checksum to detect the problem. Add check of flash read failure to detect the problem sooner. Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/202406210815.rPDRDMBi-lkp@intel.com/ Cc: stable@vger.kernel.org Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-6-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5b1ed6e6f2df15c111ee93b2b2f3d0cdaea786e1 Author: Quinn Tran Date: Wed Jul 10 22:40:55 2024 +0530 scsi: qla2xxx: Reduce fabric scan duplicate code commit beafd692461443e0fb1d61aa56886bf85ef6f5e4 upstream. For fabric scan, current code uses switch scan opcode and flags as the method to iterate through different commands to carry out the process. This makes it hard to read. This patch convert those opcode and flags into steps. In addition, this help reduce some duplicate code. Consolidate routines that handle GPNFT & GNNFT. Cc: stable@vger.kernel.org Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-10-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1e39d28440095dc3442ca3ea2eab1054852a9608 Author: Quinn Tran Date: Wed Jul 10 22:40:56 2024 +0530 scsi: qla2xxx: Use QP lock to search for bsg commit c449b4198701d828e40d60a2abd30970b74a1d75 upstream. On bsg timeout, hardware_lock is used as part of search for the srb. Instead, qpair lock should be used to iterate through different qpair. Cc: stable@vger.kernel.org Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-11-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 8192c533e89d9fb69b2490398939236b78cda79b Author: Shreyas Deodhar Date: Wed Jul 10 22:40:49 2024 +0530 scsi: qla2xxx: Fix for possible memory corruption commit c03d740152f78e86945a75b2ad541bf972fab92a upstream. Init Control Block is dereferenced incorrectly. Correctly dereference ICB Cc: stable@vger.kernel.org Signed-off-by: Shreyas Deodhar Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-4-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 50ed642a860ff6c1423c66709b1b48f27822e14d Author: Quinn Tran Date: Wed Jul 10 22:40:47 2024 +0530 scsi: qla2xxx: Unable to act on RSCN for port online commit c3d98b12eef8db436e32f1a8c5478be57dc15621 upstream. The device does not come online when the target port is online. There were multiple RSCNs indicating multiple devices were affected. Driver is in the process of finishing a fabric scan. A new RSCN (device up) arrived at the tail end of the last fabric scan. Driver mistakenly thinks the new RSCN is being taken care of by the previous fabric scan, where this notification is cleared and not acted on. The laser needs to be blinked again to get the device to show up. To prevent driver from accidentally clearing the RSCN notification, each RSCN is given a generation value. A fabric scan will scan for that generation(s). Any new RSCN arrive after the scan start will have a new generation value. This will trigger another scan to get latest data. The RSCN notification flag will be cleared when the scan is associate to that generation. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202406210538.w875N70K-lkp@intel.com/ Fixes: bb2ca6b3f09a ("scsi: qla2xxx: Relogin during fabric disturbance") Cc: stable@vger.kernel.org Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-2-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b35d6d5a2f38605cddea7d5c64cded894fbe8ede Author: Manish Rangankar Date: Wed Jul 10 22:40:53 2024 +0530 scsi: qla2xxx: During vport delete send async logout explicitly commit 76f480d7c717368f29a3870f7d64471ce0ff8fb2 upstream. During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting. BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 Send out async logout explicitly for all the ports during vport delete. Cc: stable@vger.kernel.org Signed-off-by: Manish Rangankar Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-8-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 81079920f1163c6e9262e21c0fd878ba32d8a9d2 Author: Justin Tee Date: Fri Jun 28 10:20:05 2024 -0700 scsi: lpfc: Allow DEVICE_RECOVERY mode after RSCN receipt if in PRLI_ISSUE state commit 9609385dd91b26751019b22ca9bfa4bec7602ae1 upstream. Certain vendor specific targets initially register with the fabric as an initiator function first and then re-register as a target function afterwards. The timing of the target function re-registration can cause a race condition such that the driver is stuck assuming the remote port as an initiator function and never discovers the target's hosted LUNs. Expand the nlp_state qualifier to also include NLP_STE_PRLI_ISSUE because the state means that PRLI was issued but we have not quite reached MAPPED_NODE state yet. If we received an RSCN in the PRLI_ISSUE state, then we should restart discovery again by going into DEVICE_RECOVERY. Fixes: dded1dc31aa4 ("scsi: lpfc: Modify when a node should be put in device recovery mode during RSCN") Cc: # v6.6+ Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240628172011.25921-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7816a528add16f4e0b20b7513f61ef86f84d6d5c Author: Joy Chakraborty Date: Wed Jun 12 08:36:35 2024 +0000 rtc: cmos: Fix return value of nvmem callbacks commit 1c184baccf0d5e2ef4cc1562261d0e48508a1c2b upstream. Read/write callbacks registered with nvmem core expect 0 to be returned on success and a negative value to be returned on failure. cmos_nvram_read()/cmos_nvram_write() currently return the number of bytes read or written, fix to return 0 on success and -EIO incase number of bytes requested was not read or written. Fixes: 8b5b7958fd1c ("rtc: cmos: use generic nvmem") Cc: stable@vger.kernel.org Signed-off-by: Joy Chakraborty Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240612083635.1253039-1-joychakr@google.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 5fdb0de5465b746778e7433c139fdc4eddaa1fc8 Author: Tvrtko Ursulin Date: Mon Jul 8 08:56:32 2024 +0100 mm/numa_balancing: teach mpol_to_str about the balancing mode commit af649773fb25250cd22625af021fb6275c56a3ee upstream. Since balancing mode was added in bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes"), it was possible to set this mode but it wouldn't be shown in /proc//numa_maps since there was no support for it in the mpol_to_str() helper. Furthermore, because the balancing mode sets the MPOL_F_MORON flag, it would be displayed as 'default' due a workaround introduced a few years earlier in 8790c71a18e5 ("mm/mempolicy.c: fix mempolicy printing in numa_maps"). To tidy this up we implement two changes: Replace the MPOL_F_MORON check by pointer comparison against the preferred_node_policy array. By doing this we generalise the current special casing and replace the incorrect 'default' with the correct 'bind' for the mode. Secondly, we add a string representation and corresponding handling for the MPOL_F_NUMA_BALANCING flag. With the two changes together we start showing the balancing flag when it is set and therefore complete the fix. Representation format chosen is to separate multiple flags with vertical bars, following what existed long time ago in kernel 2.6.25. But as between then and now there wasn't a way to display multiple flags, this patch does not change the format in practice. Some /proc//numa_maps output examples: 555559580000 bind=balancing:0-1,3 file=... 555585800000 bind=balancing|static:0,2 file=... 555635240000 prefer=relative:0 file= Link: https://lkml.kernel.org/r/20240708075632.95857-1-tursulin@igalia.com Signed-off-by: Tvrtko Ursulin Fixes: bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes") References: 8790c71a18e5 ("mm/mempolicy.c: fix mempolicy printing in numa_maps") Reviewed-by: "Huang, Ying" Cc: Mel Gorman Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rik van Riel Cc: Johannes Weiner Cc: "Matthew Wilcox (Oracle)" Cc: Dave Hansen Cc: Andi Kleen Cc: Michal Hocko Cc: David Rientjes Cc: [5.12+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f8ae38f1dfe652779c7c613facbc257cec00ac44 Author: Shenwei Wang Date: Wed Jul 3 11:32:50 2024 -0500 irqchip/imx-irqsteer: Handle runtime power management correctly commit 33b1c47d1fc0b5f06a393bb915db85baacba18ea upstream. The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context. [ tglx: Rewrote change log, added Fixes tag ] Fixes: 0136afa08967 ("irqchip: Add driver for imx-irqsteer controller") Signed-off-by: Shenwei Wang Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240703163250.47887-1-shenwei.wang@nxp.com Signed-off-by: Greg Kroah-Hartman commit 0a1230db5d67e7f54ffcdf7712eebf031b7ba294 Author: Mateusz Jończyk Date: Thu Jul 11 22:23:16 2024 +0200 md/raid1: set max_sectors during early return from choose_slow_rdev() commit 36a5c03f232719eb4e2d925f4d584e09cfaf372c upstream. Linux 6.9+ is unable to start a degraded RAID1 array with one drive, when that drive has a write-mostly flag set. During such an attempt, the following assertion in bio_split() is hit: BUG_ON(sectors <= 0); Call Trace: ? bio_split+0x96/0xb0 ? exc_invalid_op+0x53/0x70 ? bio_split+0x96/0xb0 ? asm_exc_invalid_op+0x1b/0x20 ? bio_split+0x96/0xb0 ? raid1_read_request+0x890/0xd20 ? __call_rcu_common.constprop.0+0x97/0x260 raid1_make_request+0x81/0xce0 ? __get_random_u32_below+0x17/0x70 ? new_slab+0x2b3/0x580 md_handle_request+0x77/0x210 md_submit_bio+0x62/0xa0 __submit_bio+0x17b/0x230 submit_bio_noacct_nocheck+0x18e/0x3c0 submit_bio_noacct+0x244/0x670 After investigation, it turned out that choose_slow_rdev() does not set the value of max_sectors in some cases and because of it, raid1_read_request calls bio_split with sectors == 0. Fix it by filling in this variable. This bug was introduced in commit dfa8ecd167c1 ("md/raid1: factor out choose_slow_rdev() from read_balance()") but apparently hidden until commit 0091c5a269ec ("md/raid1: factor out helpers to choose the best rdev from read_balance()") shortly thereafter. Cc: stable@vger.kernel.org # 6.9.x+ Signed-off-by: Mateusz Jończyk Fixes: dfa8ecd167c1 ("md/raid1: factor out choose_slow_rdev() from read_balance()") Cc: Song Liu Cc: Yu Kuai Cc: Paul Luse Cc: Xiao Ni Cc: Mariusz Tkaczyk Link: https://lore.kernel.org/linux-raid/20240706143038.7253-1-mat.jonczyk@o2.pl/ Signed-off-by: Greg Kroah-Hartman -- Tested on both Linux 6.10 and 6.9.8. Inside a VM, mdadm testsuite for RAID1 on 6.10 did not find any problems: ./test --dev=loop --no-error --raidtype=raid1 (on 6.9.8 there was one failure, caused by external bitmap support not compiled in). Notes: - I was reliably getting deadlocks when adding / removing devices on such an array - while the array was loaded with fsstress with 20 concurrent processes. When the array was idle or loaded with fsstress with 8 processes, no such deadlocks happened in my tests. This occurred also on unpatched Linux 6.8.0 though, but not on 6.1.97-rc1, so this is likely an independent regression (to be investigated). - I was also getting deadlocks when adding / removing the bitmap on the array in similar conditions - this happened on Linux 6.1.97-rc1 also though. fsstress with 8 concurrent processes did cause it only once during many tests. - in my testing, there was once a problem with hot adding an internal bitmap to the array: mdadm: Cannot add bitmap while array is resyncing or reshaping etc. mdadm: failed to set internal bitmap. even though no such reshaping was happening according to /proc/mdstat. This seems unrelated, though. Reviewed-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240711202316.10775-1-mat.jonczyk@o2.pl commit 3a7f23e1d81ce7a011c15636c182102b365fbb93 Author: Herve Codina Date: Fri Jun 14 19:32:04 2024 +0200 irqdomain: Fixed unbalanced fwnode get and put commit 6ce3e98184b625d2870991880bf9586ded7ea7f9 upstream. fwnode_handle_get(fwnode) is called when a domain is created with fwnode passed as a function parameter. fwnode_handle_put(domain->fwnode) is called when the domain is destroyed but during the creation a path exists that does not set domain->fwnode. If this path is taken, the fwnode get will never be put. To avoid the unbalanced get and put, set domain->fwnode unconditionally. Fixes: d59f6617eef0 ("genirq: Allow fwnode to carry name information only") Signed-off-by: Herve Codina Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240614173232.1184015-4-herve.codina@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 95065edb8ebb27771d5f1e898eef6ab43dc6c87c Author: Zijun Hu Date: Tue Jul 2 22:51:51 2024 +0800 devres: Fix memory leakage caused by driver API devm_free_percpu() commit bd50a974097bb82d52a458bd3ee39fb723129a0c upstream. It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). Fixes: ff86aae3b411 ("devres: add devm_alloc_percpu()") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/1719931914-19035-3-git-send-email-quic_zijuhu@quicinc.com Signed-off-by: Greg Kroah-Hartman commit c885ca965a4cf3b6532e1fc0b57a4777eac428c6 Author: Zijun Hu Date: Tue Jul 2 22:51:50 2024 +0800 devres: Fix devm_krealloc() wasting memory commit c884e3249f753dcef7a2b2023541ac1dc46b318e upstream. Driver API devm_krealloc() calls alloc_dr() with wrong argument @total_new_size, so causes more memory to be allocated than required fix this memory waste by using @new_size as the argument for alloc_dr(). Fixes: f82485722e5d ("devres: provide devm_krealloc()") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Link: https://lore.kernel.org/r/1719931914-19035-2-git-send-email-quic_zijuhu@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 205dfd57a8ee51ade14f3775a0850a0b46772122 Author: Yijie Yang Date: Mon Jun 24 10:19:16 2024 +0800 dt-bindings: phy: qcom,qmp-usb: fix spelling error commit 3d83abcae6e8fa6698f6b0a026ca650302bdbfd8 upstream. Correct the spelling error, changing 'com' to 'qcom'. Cc: stable@vger.kernel.org Fixes: f75a4b3a6efc ("dt-bindings: phy: qcom,qmp-usb: Add QDU1000 USB3 PHY") Signed-off-by: Yijie Yang Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240624021916.2033062-1-quic_yijiyang@quicinc.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 292081c4e7f575a79017d5cbe1a0ec042783976f Author: Ahmed Zaki Date: Fri Jun 14 07:18:42 2024 -0600 ice: Add a per-VF limit on number of FDIR filters commit 6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 upstream. While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice. CC: stable@vger.kernel.org Fixes: 1f7ea1cd6a37 ("ice: Enable FDIR Configure for AVF") Reviewed-by: Przemek Kitszel Suggested-by: Sridhar Samudrala Signed-off-by: Ahmed Zaki Reviewed-by: Wojciech Drewek Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman commit edd21c8a929f9e422bae5b47669d396e241bcc6e Author: Bailey Forrest Date: Wed Jul 24 07:34:31 2024 -0700 gve: Fix an edge case for TSO skb validity check commit 36e3b949e35964e22b9a57f960660fc599038dd4 upstream. The NIC requires each TSO segment to not span more than 10 descriptors. NIC further requires each descriptor to not exceed 16KB - 1 (GVE_TX_MAX_BUF_SIZE_DQO). The descriptors for an skb are generated by gve_tx_add_skb_no_copy_dqo() for DQO RDA queue format. gve_tx_add_skb_no_copy_dqo() loops through each skb frag and generates a descriptor for the entire frag if the frag size is not greater than GVE_TX_MAX_BUF_SIZE_DQO. If the frag size is greater than GVE_TX_MAX_BUF_SIZE_DQO, it is split into descriptor(s) of size GVE_TX_MAX_BUF_SIZE_DQO and a descriptor is generated for the remainder (frag size % GVE_TX_MAX_BUF_SIZE_DQO). gve_can_send_tso() checks if the descriptors thus generated for an skb would meet the requirement that each TSO-segment not span more than 10 descriptors. However, the current code misses an edge case when a TSO segment spans multiple descriptors within a large frag. This change fixes the edge case. gve_can_send_tso() relies on the assumption that max gso size (9728) is less than GVE_TX_MAX_BUF_SIZE_DQO and therefore within an skb fragment a TSO segment can never span more than 2 descriptors. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Praveen Kaligineedi Signed-off-by: Bailey Forrest Reviewed-by: Jeroen de Borst Cc: stable@vger.kernel.org Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20240724143431.3343722-1-pkaligineedi@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d4663536754defff75ff1eca0aaebc41da165a8d Author: Zijun Hu Date: Thu May 30 21:14:37 2024 +0800 kobject_uevent: Fix OOB access within zap_modalias_env() commit dd6e9894b451e7c85cceb8e9dc5432679a70e7dc upstream. zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove. Fixes: 9b3fa47d4a76 ("kobject: fix suppressing modalias in uevents delivered over netlink") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu Reviewed-by: Lk Sii Link: https://lore.kernel.org/r/1717074877-11352-1-git-send-email-quic_zijuhu@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 78672d49d3eebbcda3589f4d6e589caf357c5a59 Author: Will Deacon Date: Thu Jul 25 10:03:45 2024 +0100 arm64: mm: Fix lockless walks with static and dynamic page-table folding commit 36639013b3462c06ff8e3400a427f775b4fc97f5 upstream. Lina reports random oopsen originating from the fast GUP code when 16K pages are used with 4-level page-tables, the fourth level being folded at runtime due to lack of LPA2. In this configuration, the generic implementation of p4d_offset_lockless() will return a 'p4d_t *' corresponding to the 'pgd_t' allocated on the stack of the caller, gup_fast_pgd_range(). This is normally fine, but when the fourth level of page-table is folded at runtime, pud_offset_lockless() will offset from the address of the 'p4d_t' to calculate the address of the PUD in the same page-table page. This results in a stray stack read when the 'p4d_t' has been allocated on the stack and can send the walker into the weeds. Fix the problem by providing our own definition of p4d_offset_lockless() when CONFIG_PGTABLE_LEVELS <= 4 which returns the real page-table pointer rather than the address of the local stack variable. Cc: Catalin Marinas Cc: Ard Biesheuvel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/50360968-13fb-4e6f-8f52-1725b3177215@asahilina.net Fixes: 0dd4f60a2c76 ("arm64: mm: Add support for folding PUDs at runtime") Reported-by: Asahi Lina Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20240725090345.28461-1-will@kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 00a2ac6c89ebe61e42df8a7851f10d2de85c259c Author: Takashi Iwai Date: Thu Jul 25 08:54:28 2024 +0200 ASoC: amd: yc: Support mic on Lenovo Thinkpad E16 Gen 2 commit 1d9ce4440414c92acb17eece3218fe5c92b141e3 upstream. Lenovo Thinkpad E16 Gen 2 AMD model (model 21M5) needs a corresponding quirk entry for making the internal mic working. Link: https://bugzilla.suse.com/show_bug.cgi?id=1228269 Cc: stable@vger.kernel.org Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20240725065442.9293-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 834188d88a8066ee0958b5b2e28ebc6abb32a9e4 Author: Peter Ujfalusi Date: Wed Jul 24 11:19:32 2024 +0300 ASoC: SOF: ipc4-topology: Preserve the DMA Link ID for ChainDMA on unprepare commit e6fc5fcaeffa04a3fa1db8dfccdfd4b6001c0446 upstream. The DMA Link ID is set to the IPC message's primary during dai_config, which is only during hw_params. During xrun handling the hw_params is not called and the DMA Link ID information will be lost. All other fields in the message expected to be 0 for re-configuration, only the DMA Link ID needs to be preserved and the in case of repeated dai_config, it is correctly updated (masked and then set). Cc: stable@vger.kernel.org Fixes: ca5ce0caa67f ("ASoC: SOF: ipc4/intel: Add support for chained DMA") Link: https://github.com/thesofproject/linux/issues/5116 Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20240724081932.24542-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5eca92031ffe26acd068cee66a378966c4bad946 Author: Peter Ujfalusi Date: Wed Jul 24 11:19:31 2024 +0300 ASoC: SOF: ipc4-topology: Only handle dai_config with HW_PARAMS for ChainDMA commit ae67ed9010a7b52933ad1038d13df8a3aae34b83 upstream. The DMA Link ID is only valid in snd_sof_dai_config_data when the dai_config is called with HW_PARAMS. The commit that this patch fixes is actually moved a code section without changing it, the same bug exists in the original code, needing different patch to kernel prior to 6.9 kernels. Cc: stable@vger.kernel.org Fixes: 3858464de57b ("ASoC: SOF: ipc4-topology: change chain_dma handling in dai_config") Link: https://github.com/thesofproject/linux/issues/5116 Signed-off-by: Peter Ujfalusi Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://patch.msgid.link/20240724081932.24542-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4a9a52b70cce1ac017bafbf613dd08d076b8eec9 Author: Suren Baghdasaryan Date: Wed Jul 17 14:28:44 2024 -0700 alloc_tag: outline and export free_reserved_page() commit b3bebe44306e23827397d0d774d206e3fa374041 upstream. Outline and export free_reserved_page() because modules use it and it in turn uses page_ext_{get|put} which should not be exported. The same result could be obtained by outlining {get|put}_page_tag_ref() but that would have higher performance impact as these functions are used in more performance critical paths. Link: https://lkml.kernel.org/r/20240717212844.2749975-1-surenb@google.com Fixes: dcfe378c81f7 ("lib: introduce support for page allocation tagging") Signed-off-by: Suren Baghdasaryan Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202407080044.DWMC9N9I-lkp@intel.com/ Suggested-by: Christoph Hellwig Suggested-by: Vlastimil Babka Acked-by: Vlastimil Babka Cc: Kees Cook Cc: Kent Overstreet Cc: Pasha Tatashin Cc: Sourav Panda Cc: [6.10] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a1e78bf940c4c375313b44a4a3b01cf2f6754c6e Author: Nathan Chancellor Date: Fri Jul 26 11:05:00 2024 -0700 kbuild: Fix '-S -c' in x86 stack protector scripts commit 3415b10a03945b0da4a635e146750dfe5ce0f448 upstream. After a recent change in clang to stop consuming all instances of '-S' and '-c' [1], the stack protector scripts break due to the kernel's use of -Werror=unused-command-line-argument to catch cases where flags are not being properly consumed by the compiler driver: $ echo | clang -o - -x c - -S -c -Werror=unused-command-line-argument clang: error: argument unused during compilation: '-c' [-Werror,-Wunused-command-line-argument] This results in CONFIG_STACKPROTECTOR getting disabled because CONFIG_CC_HAS_SANE_STACKPROTECTOR is no longer set. '-c' and '-S' both instruct the compiler to stop at different stages of the pipeline ('-S' after compiling, '-c' after assembling), so having them present together in the same command makes little sense. In this case, the test wants to stop before assembling because it is looking at the textual assembly output of the compiler for either '%fs' or '%gs', so remove '-c' from the list of arguments to resolve the error. All versions of GCC continue to work after this change, along with versions of clang that do or do not contain the change mentioned above. Cc: stable@vger.kernel.org Fixes: 4f7fd4d7a791 ("[PATCH] Add the -fstack-protector option to the CFLAGS") Fixes: 60a5317ff0f4 ("x86: implement x86_32 stack protector") Link: https://github.com/llvm/llvm-project/commit/6461e537815f7fa68cef06842505353cf5600e9c [1] Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 8a83f0e5dda0ec1c40112ede69ed72745dbdc6f8 Author: Ross Lagerwall Date: Wed Jul 17 17:20:16 2024 +0100 decompress_bunzip2: fix rare decompression failure commit bf6acd5d16057d7accbbb1bf7dc6d8c56eeb4ecc upstream. The decompression code parses a huffman tree and counts the number of symbols for a given bit length. In rare cases, there may be >= 256 symbols with a given bit length, causing the unsigned char to overflow. This causes a decompression failure later when the code tries and fails to find the bit length for a given symbol. Since the maximum number of symbols is 258, use unsigned short instead. Link: https://lkml.kernel.org/r/20240717162016.1514077-1-ross.lagerwall@citrix.com Fixes: bc22c17e12c1 ("bzip2/lzma: library support for gzip, bzip2 and lzma decompression") Signed-off-by: Ross Lagerwall Cc: Alain Knaff Cc: "H. Peter Anvin" Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 96b74765425c52774393f76dd0cae378d8d1d24f Author: Ram Tummala Date: Tue Jul 9 18:45:39 2024 -0700 mm: fix old/young bit handling in the faulting path commit 4cd7ba16a0afb36550eed7690e73d3e7a743fa96 upstream. Commit 3bd786f76de2 ("mm: convert do_set_pte() to set_pte_range()") replaced do_set_pte() with set_pte_range() and that introduced a regression in the following faulting path of non-anonymous vmas which caused the PTE for the faulting address to be marked as old instead of young. handle_pte_fault() do_pte_missing() do_fault() do_read_fault() || do_cow_fault() || do_shared_fault() finish_fault() set_pte_range() The polarity of prefault calculation is incorrect. This leads to prefault being incorrectly set for the faulting address. The following check will incorrectly mark the PTE old rather than young. On some architectures this will cause a double fault to mark it young when the access is retried. if (prefault && arch_wants_old_prefaulted_pte()) entry = pte_mkold(entry); On a subsequent fault on the same address, the faulting path will see a non NULL vmf->pte and instead of reaching the do_pte_missing() path, PTE will then be correctly marked young in handle_pte_fault() itself. Due to this bug, performance degradation in the fault handling path will be observed due to unnecessary double faulting. Link: https://lkml.kernel.org/r/20240710014539.746200-1-rtummala@nvidia.com Fixes: 3bd786f76de2 ("mm: convert do_set_pte() to set_pte_range()") Signed-off-by: Ram Tummala Reviewed-by: Yin Fengwei Cc: Alistair Popple Cc: Matthew Wilcox (Oracle) Cc: Yin Fengwei Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit f5418f48a93b69ed9e6a2281eee06b412f14a544 Author: Yang Yang Date: Wed Jul 24 15:04:12 2024 +0800 block: fix deadlock between sd_remove & sd_release commit 7e04da2dc7013af50ed3a2beb698d5168d1e594b upstream. Our test report the following hung task: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue. Cc: stable@vger.kernel.org Fixes: eec1be4c30df ("block: delete partitions later in del_gendisk") Signed-off-by: Yang Yang Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Fixes: and Cc: stable tags are missing. Otherwise this patch looks fine Link: https://lore.kernel.org/r/20240724070412.22521-1-yang.yang@vivo.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b7c51fb4c16ba75398b8718a22e3f10ad332e058 Author: Krzysztof Kozlowski Date: Mon Jul 22 08:33:09 2024 +0200 clk: samsung: fix getting Exynos4 fin_pll rate from external clocks commit f99b3feb3b0e9fca2257c90fc8317be8ee44c19a upstream. Commit 0dc83ad8bfc9 ("clk: samsung: Don't register clkdev lookup for the fixed rate clocks") claimed registering clkdev lookup is not necessary anymore, but that was not entirely true: Exynos4210/4212/4412 clock code still relied on it to get the clock rate of xxti or xusbxti external clocks. Drop that requirement by accessing already registered clk_hw when looking up the xxti/xusbxti rate. Reported-by: Artur Weber Closes: https://lore.kernel.org/all/6227c1fb-d769-462a-b79b-abcc15d3db8e@gmail.com/ Fixes: 0dc83ad8bfc9 ("clk: samsung: Don't register clkdev lookup for the fixed rate clocks") Cc: Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240722063309.60054-1-krzysztof.kozlowski@linaro.org Tested-by: Artur Weber # Exynos4212 Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 154d33dc8de81a9f61fa8f4d2004f0a2f2d829fe Author: Fedor Pchelkin Date: Thu Feb 29 23:42:36 2024 +0300 ubi: eba: properly rollback inside self_check_eba commit 745d9f4a31defec731119ee8aad8ba9f2536dd9a upstream. In case of a memory allocation failure in the volumes loop we can only process the already allocated scan_eba and fm_eba array elements on the error path - others are still uninitialized. Found by Linux Verification Center (linuxtesting.org). Fixes: 00abf3041590 ("UBI: Add self_check_eba()") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit f6386c256b79bdb992e1239b01326437526fec76 Author: Bastien Curutchet Date: Thu Jul 18 13:55:34 2024 +0200 clk: davinci: da8xx-cfgchip: Initialize clk_init_data before use commit a83b22754e351f13fb46596c85f667dc33da71ec upstream. The flag attribute of the struct clk_init_data isn't initialized before the devm_clk_hw_register() call. This can lead to unexpected behavior during registration. Initialize the entire clk_init_data to zero at declaration. Cc: stable@vger.kernel.org Fixes: 58e1e2d2cd89 ("clk: davinci: cfgchip: Add TI DA8XX USB PHY clocks") Signed-off-by: Bastien Curutchet Reviewed-by: David Lechner Link: https://lore.kernel.org/r/20240718115534.41513-1-bastien.curutchet@bootlin.com Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 366c3f688dd0288cbe38af1d3a886b5c62372e4a Author: Ryusuke Konishi Date: Thu Jul 25 14:20:07 2024 +0900 nilfs2: handle inconsistent state in nilfs_btnode_create_block() commit 4811f7af6090e8f5a398fbdd766f903ef6c0d787 upstream. Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug. Link: https://lkml.kernel.org/r/20240725052007.4562-1-konishi.ryusuke@gmail.com Fixes: a60be987d45d ("nilfs2: B-tree node cache") Signed-off-by: Ryusuke Konishi Reported-by: syzbot+89cc4f2324ed37988b60@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=89cc4f2324ed37988b60 Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9e5f087b81a715aa3fd6e9cdb7c0c5a98230d030 Author: Joy Zou Date: Fri May 10 11:09:34 2024 +0800 dmaengine: fsl-edma: change the memory access from local into remote mode in i.MX 8QM commit 8ddad558997002ce67980e30c9e8dfaa696e163b upstream. Fix the issue where MEM_TO_MEM fail on i.MX8QM due to the requirement that both source and destination addresses need pass through the IOMMU. Typically, peripheral FIFO addresses bypass the IOMMU, necessitating only one of the source or destination to go through it. Set "is_remote" to true to ensure both source and destination addresses pass through the IOMMU. iMX8 Spec define "Local" and "Remote" bus as below. Local bus: bypass IOMMU to directly access other peripheral register, such as FIFO. Remote bus: go through IOMMU to access system memory. The test fail log as follow: [ 66.268506] dmatest: dma0chan0-copy0: result #1: 'test timed out' with src_off=0x100 dst_off=0x80 len=0x3ec0 (0) [ 66.278785] dmatest: dma0chan0-copy0: summary 1 tests, 1 failures 0.32 iops 4 KB/s (0) Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Joy Zou Cc: stable@vger.kernel.org Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20240510030959.703663-1-joy.zou@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit bd9b941078bc4181e073d0f67ff8434b08fb8a95 Author: Sunmin Jeong Date: Wed Jul 10 20:51:43 2024 +0900 f2fs: use meta inode for GC of COW file commit f18d0076933689775fe7faeeb10ee93ff01be6ab upstream. In case of the COW file, new updates and GC writes are already separated to page caches of the atomic file and COW file. As some cases that use the meta inode for GC, there are some race issues between a foreground thread and GC thread. To handle them, we need to take care when to invalidate and wait writeback of GC pages in COW files as the case of using the meta inode. Also, a pointer from the COW inode to the original inode is required to check the state of original pages. For the former, we can solve the problem by using the meta inode for GC of COW files. Then let's get a page from the original inode in move_data_block when GCing the COW file to avoid race condition. Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Cc: stable@vger.kernel.org #v5.19+ Reviewed-by: Sungjong Seo Reviewed-by: Yeongjin Gil Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 0ecfe3974b2162a029c00f54236f344c4cfe003f Author: Sunmin Jeong Date: Wed Jul 10 20:51:17 2024 +0900 f2fs: use meta inode for GC of atomic file commit b40a2b00370931b0c50148681dd7364573e52e6b upstream. The page cache of the atomic file keeps new data pages which will be stored in the COW file. It can also keep old data pages when GCing the atomic file. In this case, new data can be overwritten by old data if a GC thread sets the old data page as dirty after new data page was evicted. Also, since all writes to the atomic file are redirected to COW inodes, GC for the atomic file is not working well as below. f2fs_gc(gc_type=FG_GC) - select A as a victim segment do_garbage_collect - iget atomic file's inode for block B move_data_page f2fs_do_write_data_page - use dn of cow inode - set fio->old_blkaddr from cow inode - seg_freed is 0 since block B is still valid - goto gc_more and A is selected as victim again To solve the problem, let's separate GC writes and updates in the atomic file by using the meta inode for GC writes. Fixes: 3db1de0e582c ("f2fs: change the current atomic write way") Cc: stable@vger.kernel.org #v5.19+ Reviewed-by: Sungjong Seo Reviewed-by: Yeongjin Gil Signed-off-by: Sunmin Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1e7725814361c8c008d131db195cef8274ff26b8 Author: Chao Yu Date: Mon Jun 3 09:07:45 2024 +0800 f2fs: fix return value of f2fs_convert_inline_inode() commit a8eb3de28e7a365690c61161e7a07a4fc7c60bbf upstream. If device is readonly, make f2fs_convert_inline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below: f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [inline] file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [inline] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/fs.h:2114 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: stable@vger.kernel.org Reported-by: syzbot+848062ba19c8782ca5c8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000d103ce06174d7ec3@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 2434344559f6743efb3ac15d11af9a0db9543bd3 Author: Chao Yu Date: Tue Jun 4 15:56:36 2024 +0800 f2fs: fix to don't dirty inode for readonly filesystem commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream. syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). Cc: stable@vger.kernel.org Reported-by: syzbot+31e4659a3fe953aec2f4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000e890bc0609a55cff@google.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 2ea700595158b718a587744103aa2dfff2624c6e Author: Chao Yu Date: Thu May 23 21:29:48 2024 +0800 f2fs: fix to force buffered IO on inline_data inode commit 5c8764f8679e659c5cb295af7d32279002d13735 upstream. It will return all zero data when DIO reading from inline_data inode, it is because f2fs_iomap_begin() assign iomap->type w/ IOMAP_HOLE incorrectly for this case. We can let iomap framework handle inline data via assigning iomap->type and iomap->inline_data correctly, however, it will be a little bit complicated when handling race case in between direct IO and buffered IO. So, let's force to use buffered IO to fix this issue. Cc: stable@vger.kernel.org Reported-by: Barry Song Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit af466037fa2b263e8ea5c47285513d2487e17d90 Author: Herve Codina Date: Mon Jul 1 13:30:28 2024 +0200 ASoC: fsl: fsl_qmc_audio: Check devm_kasprintf() returned value commit e62599902327d27687693f6e5253a5d56583db58 upstream. devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Fixes: 075c7125b11c ("ASoC: fsl: Add support for QMC audio") Cc: stable@vger.kernel.org Signed-off-by: Herve Codina Link: https://patch.msgid.link/20240701113038.55144-2-herve.codina@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a28fe9105fee44f1cb1407427deb7d7a4832c258 Author: Saurav Kashyap Date: Wed Jul 10 22:40:50 2024 +0530 scsi: qla2xxx: Return ENOBUFS if sg_cnt is more than one for ELS cmds commit ce2065c4cc4f05635413f63f6dc038d7d4842e31 upstream. Firmware only supports single DSDs in ELS Pass-through IOCB (0x53h), sg cnt is decided by the SCSI ML. User is not aware of the cause of an acutal error. Return the appropriate return code that will be decoded by API and application and proper error message will be displayed to user. Fixes: 6e98016ca077 ("[SCSI] qla2xxx: Re-organized BSG interface specific code.") Cc: stable@vger.kernel.org Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-5-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0a4ae2644e2a3b3b219aad9639fb2b0691d08420 Author: Huacai Chen Date: Wed May 29 14:40:52 2024 +0800 fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed commit 2fef55d8f78383c8e6d6d4c014b9597375132696 upstream. If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page(). Cc: stable@vger.kernel.org Fixes: b46acd6a6a627d876898e ("fs/ntfs3: Add NTFS journal") Signed-off-by: Huacai Chen Signed-off-by: Konstantin Komarov Signed-off-by: Greg Kroah-Hartman commit 830dc86a2931228f6226a147028cb1805791058f Author: Li Zhijian Date: Tue Jul 23 14:44:28 2024 +0800 mm/page_alloc: fix pcp->count race between drain_pages_zone() vs __rmqueue_pcplist() commit 66eca1021a42856d6af2a9802c99e160278aed91 upstream. It's expected that no page should be left in pcp_list after calling zone_pcp_disable() in offline_pages(). Previously, it's observed that offline_pages() gets stuck [1] due to some pages remaining in pcp_list. Cause: There is a race condition between drain_pages_zone() and __rmqueue_pcplist() involving the pcp->count variable. See below scenario: CPU0 CPU1 ---------------- --------------- spin_lock(&pcp->lock); __rmqueue_pcplist() { zone_pcp_disable() { /* list is empty */ if (list_empty(list)) { /* add pages to pcp_list */ alloced = rmqueue_bulk() mutex_lock(&pcp_batch_high_lock) ... __drain_all_pages() { drain_pages_zone() { /* read pcp->count, it's 0 here */ count = READ_ONCE(pcp->count) /* 0 means nothing to drain */ /* update pcp->count */ pcp->count += alloced << order; ... ... spin_unlock(&pcp->lock); In this case, after calling zone_pcp_disable() though, there are still some pages in pcp_list. And these pages in pcp_list are neither movable nor isolated, offline_pages() gets stuck as a result. Solution: Expand the scope of the pcp->lock to also protect pcp->count in drain_pages_zone(), to ensure no pages are left in the pcp list after zone_pcp_disable() [1] https://lore.kernel.org/linux-mm/6a07125f-e720-404c-b2f9-e55f3f166e85@fujitsu.com/ Link: https://lkml.kernel.org/r/20240723064428.1179519-1-lizhijian@fujitsu.com Fixes: 4b23a68f9536 ("mm/page_alloc: protect PCP lists with a spinlock") Signed-off-by: Li Zhijian Reported-by: Yao Xingtao Reviewed-by: Vlastimil Babka Cc: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 49b22e06a947727a6d1c802d2d9ad92420b90fc5 Author: Gao Xiang Date: Mon Jul 22 11:51:10 2024 +0800 erofs: fix race in z_erofs_get_gbuf() commit 7dc5537c3f8be87e005f0844a7626c987914f8fd upstream. In z_erofs_get_gbuf(), the current task may be migrated to another CPU between `z_erofs_gbuf_id()` and `spin_lock(&gbuf->lock)`. Therefore, z_erofs_put_gbuf() will trigger the following issue which was found by stress test: <2>[772156.434168] kernel BUG at fs/erofs/zutil.c:58! .. <4>[772156.435007] <4>[772156.439237] CPU: 0 PID: 3078 Comm: stress Kdump: loaded Tainted: G E 6.10.0-rc7+ #2 <4>[772156.439239] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 1.0.0 01/01/2017 <4>[772156.439241] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[772156.439243] pc : z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.439252] lr : z_erofs_lz4_decompress+0x600/0x6a0 [erofs] .. <6>[772156.445958] stress (3127): drop_caches: 1 <4>[772156.446120] Call trace: <4>[772156.446121] z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.446761] z_erofs_lz4_decompress+0x600/0x6a0 [erofs] <4>[772156.446897] z_erofs_decompress_queue+0x740/0xa10 [erofs] <4>[772156.447036] z_erofs_runqueue+0x428/0x8c0 [erofs] <4>[772156.447160] z_erofs_readahead+0x224/0x390 [erofs] .. Fixes: f36f3010f676 ("erofs: rename per-CPU buffers to global buffer pool and make it configurable") Cc: # 6.10+ Reviewed-by: Chunhai Guo Reviewed-by: Sandeep Dhavale Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20240722035110.3456740-1-hsiangkao@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit 242cda6c45a0965568e01eb17496bb0a3ff216ca Author: Qiang Ma Date: Wed Jul 17 15:00:43 2024 +0800 efi/libstub: Zero initialize heap allocated struct screen_info commit ee8b8f5d83eb2c9caaebcf633310905ee76856e9 upstream. After calling uefi interface allocate_pool to apply for memory, we should clear 0 to prevent the possibility of using random values. Signed-off-by: Qiang Ma Cc: # v6.6+ Fixes: 732ea9db9d8a ("efi: libstub: Move screen_info handling to common code") Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 5a9a5f39376ffc7570a2622e6b2ee6013ffef190 Author: Johannes Berg Date: Tue Jul 2 09:24:41 2024 +0200 hostfs: fix dev_t handling commit 267ed02c2121b75e0eaaa338240453b576039e4a upstream. dev_t is a kernel type and may have different definitions in kernel and userspace. On 32-bit x86 this currently makes the stat structure being 4 bytes longer in the user code, causing stack corruption. However, this is (potentially) not the only problem, since dev_t is a different type on user/kernel side, so we don't know that the major/minor encoding isn't also different. Decode/encode it instead to address both problems. Cc: stable@vger.kernel.org Fixes: 74ce793bcbde ("hostfs: Fix ephemeral inodes") Link: https://patch.msgid.link/20240702092440.acc960585dd5.Id0767e12f562a69c6cd3c3262dc3d765db350cf6@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 7789a1d6792af410aa9b39a1eb237ed24fa2170a Author: tuhaowen Date: Mon Jul 8 16:04:30 2024 +0800 dev/parport: fix the array out-of-bounds risk commit ab11dac93d2d568d151b1918d7b84c2d02bacbd5 upstream. Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] Signed-off-by: tuhaowen Cc: stable Link: https://lore.kernel.org/r/20240708080430.8221-1-tuhaowen@uniontech.com Signed-off-by: Greg Kroah-Hartman commit d9954d47c73bf19c98af50d13fe56281972d3067 Author: Reka Norman Date: Wed Jun 26 15:48:34 2024 +0300 xhci: Apply XHCI_RESET_TO_DEFAULT quirk to TGL commit b4c87bc5ce9292d494d9354e25cc8ea152fbcbbd upstream. TGL systems have the same issue as ADL, where a large boot firmware delay is seen if USB ports are left in U3 at shutdown. So apply the XHCI_RESET_TO_DEFAULT quirk to TGL as well. The issue it fixes is a ~20s boot time delay when booting from S5. It affects TGL devices, and TGL support was added starting from v5.3. Cc: stable@vger.kernel.org Signed-off-by: Reka Norman Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240626124835.1023046-21-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4130526f7a8d8850638d0f9141dde8066e13196d Author: Carlos Llamas Date: Thu Jul 11 20:14:51 2024 +0000 binder: fix hang of unregistered readers commit 31643d84b8c3d9c846aa0e20bc033e46c68c7e7d upstream. With the introduction of binder_available_for_proc_work_ilocked() in commit 1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue") a binder thread can only "wait_for_proc_work" after its thread->looper has been marked as BINDER_LOOPER_STATE_{ENTERED|REGISTERED}. This means an unregistered reader risks waiting indefinitely for work since it never gets added to the proc->waiting_threads. If there are no further references to its waitqueue either the task will hang. The same applies to readers using the (e)poll interface. I couldn't find the rationale behind this restriction. So this patch restores the previous behavior of allowing unregistered threads to "wait_for_proc_work". Note that an error message for this scenario, which had previously become unreachable, is now re-enabled. Fixes: 1b77e9dcc3da ("ANDROID: binder: remove proc waitqueue") Cc: stable@vger.kernel.org Cc: Martijn Coenen Cc: Arve Hjønnevåg Signed-off-by: Carlos Llamas Link: https://lore.kernel.org/r/20240711201452.2017543-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman commit 23c57a7c88b053040d22d7cff73c7040ae9c77bc Author: Huacai Chen Date: Wed Jun 12 14:53:15 2024 +0800 PCI: loongson: Enable MSI in LS7A Root Complex commit a4bbcac11d3cea85822af8b40daed7e96bca5068 upstream. The LS7A chipset can be used as part of a PCIe Root Complex with Loongson-3C6000 and similar CPUs. In this case, DEV_LS7A_PCIE_PORT5 has a PCI_CLASS_BRIDGE_HOST class code, and it is a Type 0 Function whose config space provides access to Root Complex registers. The DEV_LS7A_PCIE_PORT5 has an MSI Capability, and its MSI Enable bit must be set before other devices below the Root Complex can use MSI. This is not the standard PCI behavior of MSI Enable, so the normal PCI MSI code does not set it. Set the DEV_LS7A_PCIE_PORT5 MSI Enable bit via a quirk so other devices below the Root Complex can use MSI. [kwilczynski: exit early to reduce indentation; commit log] Link: https://lore.kernel.org/linux-pci/20240612065315.2048110-1-chenhuacai@loongson.cn Signed-off-by: Sheng Wu Signed-off-by: Huacai Chen Signed-off-by: Krzysztof Wilczyński [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b27d26d07b187179a0668880f8904933abea6c63 Author: Manivannan Sadhasivam Date: Tue Apr 16 11:12:35 2024 +0530 PCI: rockchip: Use GPIOD_OUT_LOW flag while requesting ep_gpio commit 840b7a5edf88fe678c60dee88a135647c0ea4375 upstream. Rockchip platforms use 'GPIO_ACTIVE_HIGH' flag in the devicetree definition for ep_gpio. This means, whatever the logical value set by the driver for the ep_gpio, physical line will output the same logic level. For instance, gpiod_set_value_cansleep(rockchip->ep_gpio, 0); --> Level low gpiod_set_value_cansleep(rockchip->ep_gpio, 1); --> Level high But while requesting the ep_gpio, GPIOD_OUT_HIGH flag is currently used. Now, this also causes the physical line to output 'high' creating trouble for endpoint devices during host reboot. When host reboot happens, the ep_gpio will initially output 'low' due to the GPIO getting reset to its POR value. Then during host controller probe, it will output 'high' due to GPIOD_OUT_HIGH flag. Then during rockchip_pcie_host_init_port(), it will first output 'low' and then 'high' indicating the completion of controller initialization. On the endpoint side, each output 'low' of ep_gpio is accounted for PERST# assert and 'high' for PERST# deassert. With the above mentioned flow during host reboot, endpoint will witness below state changes for PERST#: (1) PERST# assert - GPIO POR state (2) PERST# deassert - GPIOD_OUT_HIGH while requesting GPIO (3) PERST# assert - rockchip_pcie_host_init_port() (4) PERST# deassert - rockchip_pcie_host_init_port() Now the time interval between (2) and (3) is very short as both happen during the driver probe(), and this results in a race in the endpoint. Because, before completing the PERST# deassertion in (2), endpoint got another PERST# assert in (3). A proper way to fix this issue is to change the GPIOD_OUT_HIGH flag in (2) to GPIOD_OUT_LOW. Because the usual convention is to request the GPIO with a state corresponding to its 'initial/default' value and let the driver change the state of the GPIO when required. As per that, the ep_gpio should be requested with GPIOD_OUT_LOW as it corresponds to the POR value of '0' (PERST# assert in the endpoint). Then the driver can change the state of the ep_gpio later in rockchip_pcie_host_init_port() as per the initialization sequence. This fixes the firmware crash issue in Qcom based modems connected to Rockpro64 based board. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Closes: https://lore.kernel.org/mhi/20240402045647.GG2933@thinkpad/ Link: https://lore.kernel.org/linux-pci/20240416-pci-rockchip-perst-fix-v1-1-4800b1d4d954@linaro.org Reported-by: Slark Xiao Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Cc: stable@vger.kernel.org # v4.9 Signed-off-by: Greg Kroah-Hartman commit bf50d382439897064155f5f6a7f1ea3f18246e24 Author: Niklas Cassel Date: Wed Apr 17 18:42:26 2024 +0200 PCI: dw-rockchip: Fix initial PERST# GPIO value commit 28b8d7793b8573563b3d45321376f36168d77b1e upstream. PERST# is active low according to the PCIe specification. However, the existing pcie-dw-rockchip.c driver does: gpiod_set_value(..., 0); msleep(100); gpiod_set_value(..., 1); when asserting + deasserting PERST#. This is of course wrong, but because all the device trees for this compatible string have also incorrectly marked this GPIO as ACTIVE_HIGH: $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3568* $ git grep -B 10 reset-gpios arch/arm64/boot/dts/rockchip/rk3588* The actual toggling of PERST# is correct, and we cannot change it anyway, since that would break device tree compatibility. However, this driver does request the GPIO to be initialized as GPIOD_OUT_HIGH, which does cause a silly sequence where PERST# gets toggled back and forth for no good reason. Fix this by requesting the GPIO to be initialized as GPIOD_OUT_LOW (which for this driver means PERST# asserted). This will avoid an unnecessary signal change where PERST# gets deasserted (by devm_gpiod_get_optional()) and then gets asserted (by rockchip_pcie_start_link()) just a few instructions later. Before patch, debug prints on EP side, when booting RC: [ 845.606810] pci: PERST# asserted by host! [ 852.483985] pci: PERST# de-asserted by host! [ 852.503041] pci: PERST# asserted by host! [ 852.610318] pci: PERST# de-asserted by host! After patch, debug prints on EP side, when booting RC: [ 125.107921] pci: PERST# asserted by host! [ 132.111429] pci: PERST# de-asserted by host! This extra, very short, PERST# assertion + deassertion has been reported to cause issues with certain WLAN controllers, e.g. RTL8822CE. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Link: https://lore.kernel.org/linux-pci/20240417164227.398901-1-cassel@kernel.org Tested-by: Heiko Stuebner Tested-by: Jianfeng Liu Signed-off-by: Niklas Cassel Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Heiko Stuebner Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Greg Kroah-Hartman commit bfb58cc86e49d78113f48bd3dc1122c5648e1851 Author: Wei Liu Date: Mon Jul 1 20:26:05 2024 +0000 PCI: hv: Return zero, not garbage, when reading PCI_INTERRUPT_PIN commit fea93a3e5d5e6a09eb153866d2ce60ea3287a70d upstream. The intent of the code snippet is to always return 0 for both PCI_INTERRUPT_LINE and PCI_INTERRUPT_PIN. The check misses PCI_INTERRUPT_PIN. This patch fixes that. This is discovered by this call in VFIO: pci_read_config_byte(vdev->pdev, PCI_INTERRUPT_PIN, &pin); The old code does not set *val to 0 because it misses the check for PCI_INTERRUPT_PIN. Garbage is returned in that case. Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Link: https://lore.kernel.org/linux-pci/20240701202606.129606-1-wei.liu@kernel.org Signed-off-by: Wei Liu Signed-off-by: Krzysztof Wilczyński Reviewed-by: Michael Kelley Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit b16f3ea1db47a6766a9f1169244cf1fc287a7c62 Author: Lukas Wunner Date: Tue Jun 18 12:54:55 2024 +0200 PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal commit 11a1f4bc47362700fcbde717292158873fb847ed upstream. Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resume_noirq phase. And runtime resume is always awaited before a PCI device is removed.) However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected. Add the missing reference acquisition. Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler() Fixes: 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset") Closes: https://lore.kernel.org/r/20240612181625.3604512-3-kbusch@meta.com/ Link: https://lore.kernel.org/linux-pci/8e4bcd4116fd94f592f2bf2749f168099c480ddf.1718707743.git.lukas@wunner.de Reported-by: Keith Busch Tested-by: Keith Busch Signed-off-by: Lukas Wunner Signed-off-by: Krzysztof Wilczyński Reviewed-by: Keith Busch Reviewed-by: Mika Westerberg Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kroah-Hartman commit 43c6b8d369d8f494415878c4eb84bc435e474093 Author: John David Anglin Date: Mon Jul 1 09:42:41 2024 -0400 parisc: Fix warning at drivers/pci/msi/msi.h:121 commit 4c29ab84cfec17081aae7a7a28f8d2c93c42dcae upstream. Fix warning at drivers/pci/msi/msi.h:121. Recently, I added a PCI to PCIe bridge adaptor and a PCIe NVME card to my rp3440. Then, I noticed this warning at boot: WARNING: CPU: 0 PID: 10 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x68/0x90 CPU: 0 PID: 10 Comm: kworker/u32:0 Not tainted 6.9.7-parisc64 #1 Debian 6.9.7-1 Hardware name: 9000/800/rp3440 Workqueue: async async_run_entry_fn We need to select PCI_MSI_ARCH_FALLBACKS when PCI_MSI is selected. Signed-off-by: John David Anglin Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 985d3c869aa6c4309a30453ec9d96bebfbbd0623 Author: Ilpo Järvinen Date: Mon May 27 16:26:15 2024 +0300 hwrng: amd - Convert PCIBIOS_* return codes to errnos commit 14cba6ace79627a57fb9058582b03f0ed3832390 upstream. amd_rng_mod_init() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned as is but amd_rng_mod_init() is a module_init() function that should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver") Cc: stable@vger.kernel.org Signed-off-by: Ilpo Järvinen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 96852136af63824e8202a132375b36c1ea922bd0 Author: Thomas Huth Date: Tue Jul 2 14:17:37 2024 +0200 drm/fbdev-dma: Fix framebuffer mode for big endian devices commit cb31c58e8c294ff31ea842ee1fa2c06c9a9f1cc3 upstream. The drm_mode_legacy_fb_format() function only generates formats suitable for little endian devices. switch to drm_driver_legacy_fb_format() here instead to take the device endianness into consideration, too. Suggested-by: Thomas Zimmermann Signed-off-by: Thomas Huth Reviewed-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Signed-off-by: Thomas Zimmermann Fixes: 6ae2ff23aa43 ("drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()") Cc: Geert Uytterhoeven Cc: Javier Martinez Canillas Cc: Hamza Mahfooz Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: # v6.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20240702121737.522878-1-thuth@redhat.com Signed-off-by: Greg Kroah-Hartman commit d0facbb37293a16c3cade909c55d001cc8e4de24 Author: Thomas Zimmermann Date: Mon Jun 17 13:06:27 2024 +0200 fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes commit c2bc958b2b03e361f14df99983bc64a39a7323a3 upstream. Test the vesa_attributes field in struct screen_info for compatibility with VGA hardware. Vesafb currently tests bit 1 in screen_info's capabilities field which indicates a 64-bit lfb address and is unrelated to VGA compatibility. Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in the mode's attributes field signals VGA compatibility. The mode is compatible with VGA hardware if the bit is clear. In that case, the driver can access VGA state of the VBE's underlying hardware. The vesafb driver uses this feature to program the color LUT in palette modes. Without, colors might be incorrect. The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix incorrect logo colors in x86_64"). It incorrectly stores the mode attributes in the screen_info's capabilities field and updates vesafb accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") fixed the screen_info, but did not update vesafb. Color output still tends to work, because bit 1 in capabilities is usually 0. Besides fixing the bug in vesafb, this commit introduces a helper that reads the correct bit from screen_info. Signed-off-by: Thomas Zimmermann Fixes: 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code") Reviewed-by: Javier Martinez Canillas Cc: # v2.6.23+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 4b89bfaefb5fe0dd346b32b360c561a059b77bba Author: Alan Stern Date: Thu Jun 6 09:57:55 2024 -0400 tools/memory-model: Fix bug in lock.cat commit 4c830eef806679dc243e191f962c488dd9d00708 upstream. Andrea reported that the following innocuous litmus test: C T {} P0(spinlock_t *x) { int r0; spin_lock(x); spin_unlock(x); r0 = spin_is_locked(x); } gives rise to a nonsensical empty result with no executions: $ herd7 -conf linux-kernel.cfg T.litmus Test T Required States 0 Ok Witnesses Positive: 0 Negative: 0 Condition forall (true) Observation T Never 0 0 Time T 0.00 Hash=6fa204e139ddddf2cb6fa963bad117c0 The problem is caused by a bug in the lock.cat part of the LKMM. Its computation of the rf relation for RU (read-unlocked) events is faulty; it implicitly assumes that every RU event must read from either a UL (unlock) event in another thread or from the lock's initial state. Neither is true in the litmus test above, so the computation yields no possible executions. The lock.cat code tries to make up for this deficiency by allowing RU events outside of critical sections to read from the last po-previous UL event. But it does this incorrectly, trying to keep these rfi links separate from the rfe links that might also be needed, and passing only the latter to herd7's cross() macro. The problem is fixed by merging the two sets of possible rf links for RU events and using them all in the call to cross(). Signed-off-by: Alan Stern Reported-by: Andrea Parri Closes: https://lore.kernel.org/linux-arch/ZlC0IkzpQdeGj+a3@andrea/ Tested-by: Andrea Parri Acked-by: Andrea Parri Fixes: 15553dcbca06 ("tools/memory-model: Add model support for spin_is_locked()") CC: Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit 11f4a6d2740bcd172827da43c82ed4548765dec1 Author: wangdicheng Date: Mon Jul 22 16:48:22 2024 +0800 ALSA: usb-audio: Add a quirk for Sonix HD USB Camera commit 21451dfd853e7d8e6e3fbd7ef1fbdb2f2ead12f5 upstream. Sonix HD USB Camera does not support reading the sample rate which leads to many lines of "cannot get freq at ep 0x84". This patch adds the USB ID to quirks.c and avoids those error messages. (snip) [1.789698] usb 3-3: new high-speed USB device number 2 using xhci_hcd [1.984121] usb 3-3: New USB device found, idVendor=0c45, idProduct=6340, bcdDevice= 0.00 [1.984124] usb 3-3: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [1.984127] usb 3-3: Product: USB 2.0 Camera [1.984128] usb 3-3: Manufacturer: Sonix Technology Co., Ltd. [5.440957] usb 3-3: 3:1: cannot get freq at ep 0x84 [12.130679] usb 3-3: 3:1: cannot get freq at ep 0x84 [12.175065] usb 3-3: 3:1: cannot get freq at ep 0x84 Signed-off-by: wangdicheng Cc: Link: https://patch.msgid.link/20240722084822.31620-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 590c9a623ab396ead6ce2dc63c893b4e9f3ead37 Author: Takashi Iwai Date: Mon Jul 22 10:06:04 2024 +0200 ALSA: usb-audio: Move HD Webcam quirk to the right place commit 7010d9464f7ca3ee2d75095ea2e642a9009a41ff upstream. The quirk_flags_table[] is sorted in the USB ID order, while the last fix was put at a wrong position. Adjust the entry at the right position. Fixes: 74dba2408818 ("ALSA: usb-audio: Fix microphone sound on HD webcam.") Cc: Link: https://patch.msgid.link/20240722080605.23481-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 67f2807608604930174823ed074d5438c8552985 Author: wangdicheng Date: Fri Jul 19 10:09:06 2024 +0800 ALSA: usb-audio: Fix microphone sound on HD webcam. commit 74dba240881820b46b9b1c62ef4de3bfff47fbd4 upstream. I own an external usb Webcam, HD webcam, which had low mic volume and inconsistent sound quality. Video works as expected. (snip) [ 95.473820][ 1] [ T73] usb 5-2.2: new high-speed USB device number 7 using xhci_hcd [ 95.773974][ 1] [ T73] usb 5-2.2: New USB device found, idVendor=1bcf, idProduct=2281, bcdDevice= 0.05 [ 95.783445][ 1] [ T73] usb 5-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 95.791872][ 1] [ T73] usb 5-2.2: Product: HD webcam [ 95.797001][ 1] [ T73] usb 5-2.2: Manufacturer: Sunplus IT Co [ 95.802996][ 1] [ T73] usb 5-2.2: SerialNumber: 20200513 [ 96.092610][ 2] [ T3680] usb 5-2.2: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. [ 96.102436][ 2] [ T3680] usb 5-2.2: [5] FU [Mic Capture Volume] ch = 1, val = 0/4096/1 Set up quirk cval->res to 16 for 256 levels, Set GET_SAMPLE_RATE quirk flag to stop trying to get the sample rate. Confirmed that happened anyway later due to the backoff mechanism, After 3 failures. All audio stream on device interfaces share the same values, apart from wMaxPacketSize and tSamFreq : bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 4 bNumEndpoints 1 bInterfaceClass 1 Audio Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 4 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 1 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0064 1x 100 bytes bInterval 4 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 (snip) Testing patch provides consistent good sound recording quality and volume range. (snip) [ 95.473820][ 1] [ T73] usb 5-2.2: new high-speed USB device number 7 using xhci_hcd [ 95.773974][ 1] [ T73] usb 5-2.2: New USB device found, idVendor=1bcf, idProduct=2281, bcdDevice= 0.05 [ 95.783445][ 1] [ T73] usb 5-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 95.791872][ 1] [ T73] usb 5-2.2: Product: HD webcam [ 95.797001][ 1] [ T73] usb 5-2.2: Manufacturer: Sunplus IT Co [ 95.802996][ 1] [ T73] usb 5-2.2: SerialNumber: 20200513 [ 96.110630][ 3] [ T3680] usbcore: registered new interface driver snd-usb-audio [ 96.114329][ 7] [ T3677] usb 5-2.2: Found UVC 1.00 device HD webcam (1bcf:2281) [ 96.167555][ 7] [ T3677] usbcore: registered new interface driver uvcvideo Signed-off-by: wangdicheng Cc: Link: https://patch.msgid.link/20240719020906.8078-1-wangdich9700@163.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fcb2fa8f500f5f69c76fb2bcc2ee4ccf6e29da5c Author: Takashi Iwai Date: Mon Jul 22 16:06:06 2024 +0200 ALSA: ump: Force 1 Group for MIDI1 FBs commit ac29d8ae05b770ed3f52d7a60908ab9b126f69d7 upstream. When a Function Block declares it being a legacy MIDI1 device, it has to be only with a single UMP Group. Correct the attribute when a device declares it wrongly. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Cc: Link: https://patch.msgid.link/20240722140610.10845-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d40ff156254f4d60e5cc43a65f7b2ec9686c6a26 Author: Takashi Iwai Date: Mon Jul 22 15:59:28 2024 +0200 ALSA: ump: Don't update FB name for static blocks commit 9a4ab167cfb1dea1df0c0c948205a62c7eb3b85b upstream. When a device tries to update the FB name string even if its Endpoint is declared as static, we should skip it, just already done for the FB info update reply. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Cc: Link: https://patch.msgid.link/20240722135929.8612-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2afaf0b52fb125eb31d95b8f814863e92e7454bb Author: Takashi Sakamoto Date: Fri Jul 26 00:56:40 2024 +0900 ALSA: firewire-lib: fix wrong value as length of header for CIP_NO_HEADER case commit c1839501fe3e67d98635f159dba8b170d08f6521 upstream. In a commit 1d717123bb1a ("ALSA: firewire-lib: Avoid -Wflex-array-member-not-at-end warning"), DEFINE_FLEX() macro was used to handle variable length of array for header field in struct fw_iso_packet structure. The usage of macro has a side effect that the designated initializer assigns the count of array to the given field. Therefore CIP_HEADER_QUADLETS (=2) is assigned to struct fw_iso_packet.header, while the original designated initializer assigns zero to all fields. With CIP_NO_HEADER flag, the change causes invalid length of header in isochronous packet for 1394 OHCI IT context. This bug affects all of devices supported by ALSA fireface driver; RME Fireface 400, 800, UCX, UFX, and 802. This commit fixes the bug by replacing it with the alternative version of macro which corresponds no initializer. Cc: stable@vger.kernel.org Fixes: 1d717123bb1a ("ALSA: firewire-lib: Avoid -Wflex-array-member-not-at-end warning") Reported-by: Edmund Raile Closes: https://lore.kernel.org/r/rrufondjeynlkx2lniot26ablsltnynfaq2gnqvbiso7ds32il@qk4r6xps7jh2/ Reviewed-by: Takashi Iwai Link: https://lore.kernel.org/r/20240725155640.128442-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Greg Kroah-Hartman commit 2da6a98422a81f40612b1efa90750e11350f6803 Author: Luke D. Jones Date: Tue Jul 23 13:12:24 2024 +1200 ALSA: hda/realtek: cs35l41: Fixup remaining asus strix models commit e6e18021ddd0dc5af487fb86b6d7c964e062d692 upstream. Adjust quirks for 0x3a20, 0x3a30, 0x3a50 to match the 0x3a60. This set has now been confirmed to work with this patch. Signed-off-by: Luke D. Jones Fixes: 811dd426a9b1 ("ALSA: hda/realtek: Add quirks for Asus ROG 2024 laptops using CS35L41") Cc: Link: https://patch.msgid.link/20240723011224.115579-1-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be7486f6e0d028cdbe6108349bde8a98323c4ad2 Author: Sean Christopherson Date: Fri Jun 7 10:26:08 2024 -0700 KVM: nVMX: Fold requested virtual interrupt check into has_nested_events() commit 321ef62b0c5f6f57bb8500a2ca5986052675abbf upstream. Check for a Requested Virtual Interrupt, i.e. a virtual interrupt that is pending delivery, in vmx_has_nested_events() and drop the one-off kvm_x86_ops.guest_apic_has_interrupt() hook. In addition to dropping a superfluous hook, this fixes a bug where KVM would incorrectly treat virtual interrupts _for L2_ as always enabled due to kvm_arch_interrupt_allowed(), by way of vmx_interrupt_blocked(), treating IRQs as enabled if L2 is active and vmcs12 is configured to exit on IRQs, i.e. KVM would treat a virtual interrupt for L2 as a valid wake event based on L1's IRQ blocking status. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240607172609.3205077-6-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 65d5d97e753a59e54ee8c352ff2338ae493e1e79 Author: Sean Christopherson Date: Fri Jun 7 10:26:07 2024 -0700 KVM: nVMX: Check for pending posted interrupts when looking for nested events commit 27c4fa42b11af780d49ce704f7fa67b3c2544df4 upstream. Check for pending (and notified!) posted interrupts when checking if L2 has a pending wake event, as fully posted/notified virtual interrupt is a valid wake event for HLT. Note that KVM must check vmx->nested.pi_pending to avoid prematurely waking L2, e.g. even if KVM sees a non-zero PID.PIR and PID.0N=1, the virtual interrupt won't actually be recognized until a notification IRQ is received by the vCPU or the vCPU does (nested) VM-Enter. Fixes: 26844fee6ade ("KVM: x86: never write to memory from kvm_vcpu_check_block()") Cc: stable@vger.kernel.org Cc: Maxim Levitsky Reported-by: Jim Mattson Closes: https://lore.kernel.org/all/20231207010302.2240506-1-jmattson@google.com Link: https://lore.kernel.org/r/20240607172609.3205077-5-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit b75e89946e9c5d6e9899b243fc74af637ba8c96e Author: Sean Christopherson Date: Fri Jun 7 10:26:05 2024 -0700 KVM: nVMX: Request immediate exit iff pending nested event needs injection commit 32f55e475ce2c4b8b124d335fcfaf1152ba977a1 upstream. When requesting an immediate exit from L2 in order to inject a pending event, do so only if the pending event actually requires manual injection, i.e. if and only if KVM actually needs to regain control in order to deliver the event. Avoiding the "immediate exit" isn't simply an optimization, it's necessary to make forward progress, as the "already expired" VMX preemption timer trick that KVM uses to force a VM-Exit has higher priority than events that aren't directly injected. At present time, this is a glorified nop as all events processed by vmx_has_nested_events() require injection, but that will not hold true in the future, e.g. if there's a pending virtual interrupt in vmcs02.RVI. I.e. if KVM is trying to deliver a virtual interrupt to L2, the expired VMX preemption timer will trigger VM-Exit before the virtual interrupt is delivered, and KVM will effectively hang the vCPU in an endless loop of forced immediate VM-Exits (because the pending virtual interrupt never goes away). Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240607172609.3205077-3-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 0c6c9421b0afdb315f6f14ea6736969d1ea5e3e3 Author: Sean Christopherson Date: Fri Jun 7 10:26:04 2024 -0700 KVM: nVMX: Add a helper to get highest pending from Posted Interrupt vector commit d83c36d822be44db4bad0c43bea99c8908f54117 upstream. Add a helper to retrieve the highest pending vector given a Posted Interrupt descriptor. While the actual operation is straightforward, it's surprisingly easy to mess up, e.g. if one tries to reuse lapic.c's find_highest_vector(), which doesn't work with PID.PIR due to the APIC's IRR and ISR component registers being physically discontiguous (they're 4-byte registers aligned at 16-byte intervals). To make PIR handling more consistent with respect to IRR and ISR handling, return -1 to indicate "no interrupt pending". Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240607172609.3205077-2-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a8ab69cf6f43205a1d23557183a895aaee45b4c7 Author: Sean Christopherson Date: Fri Jun 7 10:26:06 2024 -0700 KVM: VMX: Split out the non-virtualization part of vmx_interrupt_blocked() commit 322a569c4b4188a0da2812f9e952780ce09b74ba upstream. Move the non-VMX chunk of the "interrupt blocked" checks to a separate helper so that KVM can reuse the code to detect if interrupts are blocked for L2, e.g. to determine if a virtual interrupt _for L2_ is a valid wake event. If L1 disables HLT-exiting for L2, nested APICv is enabled, and L2 HLTs, then L2 virtual interrupts are valid wake events, but if and only if interrupts are unblocked for L2. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240607172609.3205077-4-seanjc@google.com Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit a849f058f1be1e5ac589c2e5c6c114294cd43a87 Author: Gautam Menghani Date: Wed Jun 5 17:09:09 2024 +0530 KVM: PPC: Book3S HV nestedv2: Add DPDES support in helper library for Guest state buffer commit 55dfb8bed6fe8bda390cc71cca878d11a9407099 upstream. Add support for using DPDES in the library for using guest state buffers. DPDES support is needed for enabling usage of doorbells in a L2 KVM on PAPR guest. Fixes: 6ccbbc33f06a ("KVM: PPC: Add helper library for Guest State Buffers") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Gautam Menghani Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://msgid.link/20240605113913.83715-2-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 86abaf9d6c98415f61bcd329c6b843eb5f4f0449 Author: Gautam Menghani Date: Wed Jun 5 17:09:10 2024 +0530 KVM: PPC: Book3S HV nestedv2: Fix doorbell emulation commit 54ec2bd9e0173b75daf84675d07c56584f96564b upstream. Doorbell emulation is broken for KVM on PAPR guests as support for DPDES was not added in the initial patch series. Due to this, a KVM on PAPR guest with SMT > 1 cannot be booted with the XICS interrupt controller as doorbells are setup in the initial probe path when using XICS (pSeries_smp_probe()). Command to replicate the above bug: qemu-system-ppc64 \ -drive file=rhel.qcow2,format=qcow2 \ -m 20G \ -smp 8,cores=1,threads=8 \ -cpu host \ -nographic \ -machine pseries,ic-mode=xics -accel kvm Add doorbell state handling support in the host KVM code to fix doorbell emulation. Fixes: 19d31c5f1157 ("KVM: PPC: Add support for nestedv2 guests") Cc: stable@vger.kernel.org # v6.7+ Signed-off-by: Gautam Menghani Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://msgid.link/20240605113913.83715-3-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit a70fcc748d41e6032266e398e7d8dc4f98e90a34 Author: Jason Chen Date: Wed Jul 3 11:44:09 2024 +0800 remoteproc: mediatek: Increase MT8188/MT8195 SCP core0 DRAM size commit 19cb6058620620e68f1a9aed99393be5c3629db4 upstream. The current DRAM size is insufficient for the HEVC feature, which requires more memory for proper functionality. This change ensures the feature has the necessary resources. Signed-off-by: Jason Chen Reviewed-by: AngeloGioacchino Del Regno Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240703034409.698-1-Jason-ch.Chen@mediatek.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit da24c4dc87d1dd59ec829c8bf72249f83bc20bea Author: Wentong Wu Date: Fri Jun 7 21:25:45 2024 +0800 media: ivsc: csi: don't count privacy on as error commit a813f168336ec4ef725b836e598cd9dc14f76dd7 upstream. Prior to the ongoing command privacy is on, it would return -1 to indicate the current privacy status, and the ongoing command would be well executed by firmware as well, so this is not error. This patch changes its behavior to notify privacy on directly by V4L2 privacy control instead of reporting error. Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule") Cc: stable@vger.kernel.org # for 6.6 and later Reported-by: Hao Yao Signed-off-by: Wentong Wu Tested-by: Jason Chen Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f083de7ff8f6bfae37fa93a821946022526a3ddc Author: Ricardo Ribalda Date: Mon Jun 10 19:17:49 2024 +0000 media: uvcvideo: Fix integer overflow calculating timestamp commit 8676a5e796fa18f55897ca36a94b2adf7f73ebd1 upstream. The function uvc_video_clock_update() supports a single SOF overflow. Or in other words, the maximum difference between the first ant the last timestamp can be 4096 ticks or 4.096 seconds. This results in a maximum value for y2 of: 0x12FBECA00, that overflows 32bits. y2 = (u32)ktime_to_ns(ktime_sub(last->host_time, first->host_time)) + y1; Extend the size of y2 to u64 to support all its values. Without this patch: # yavta -s 1920x1080 -f YUYV -t 1/5 -c /dev/video0 Device /dev/v4l/by-id/usb-Shine-Optics_Integrated_Camera_0001-video-index0 opened. Device `Integrated Camera: Integrated C' on `usb-0000:00:14.0-6' (driver 'uvcvideo') supports video, capture, without mplanes. Video format set: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200 Video format: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200 Current frame rate: 1/5 Setting frame rate to: 1/5 Frame rate set: 1/5 8 buffers requested. length: 4147200 offset: 0 timestamp type/source: mono/SoE Buffer 0/0 mapped at address 0x7947ea94c000. length: 4147200 offset: 4149248 timestamp type/source: mono/SoE Buffer 1/0 mapped at address 0x7947ea557000. length: 4147200 offset: 8298496 timestamp type/source: mono/SoE Buffer 2/0 mapped at address 0x7947ea162000. length: 4147200 offset: 12447744 timestamp type/source: mono/SoE Buffer 3/0 mapped at address 0x7947e9d6d000. length: 4147200 offset: 16596992 timestamp type/source: mono/SoE Buffer 4/0 mapped at address 0x7947e9978000. length: 4147200 offset: 20746240 timestamp type/source: mono/SoE Buffer 5/0 mapped at address 0x7947e9583000. length: 4147200 offset: 24895488 timestamp type/source: mono/SoE Buffer 6/0 mapped at address 0x7947e918e000. length: 4147200 offset: 29044736 timestamp type/source: mono/SoE Buffer 7/0 mapped at address 0x7947e8d99000. 0 (0) [-] none 0 4147200 B 507.554210 508.874282 242.836 fps ts mono/SoE 1 (1) [-] none 2 4147200 B 508.886298 509.074289 0.751 fps ts mono/SoE 2 (2) [-] none 3 4147200 B 509.076362 509.274307 5.261 fps ts mono/SoE 3 (3) [-] none 4 4147200 B 509.276371 509.474336 5.000 fps ts mono/SoE 4 (4) [-] none 5 4147200 B 509.476394 509.674394 4.999 fps ts mono/SoE 5 (5) [-] none 6 4147200 B 509.676506 509.874345 4.997 fps ts mono/SoE 6 (6) [-] none 7 4147200 B 509.876430 510.074370 5.002 fps ts mono/SoE 7 (7) [-] none 8 4147200 B 510.076434 510.274365 5.000 fps ts mono/SoE 8 (0) [-] none 9 4147200 B 510.276421 510.474333 5.000 fps ts mono/SoE 9 (1) [-] none 10 4147200 B 510.476391 510.674429 5.001 fps ts mono/SoE 10 (2) [-] none 11 4147200 B 510.676434 510.874283 4.999 fps ts mono/SoE 11 (3) [-] none 12 4147200 B 510.886264 511.074349 4.766 fps ts mono/SoE 12 (4) [-] none 13 4147200 B 511.070577 511.274304 5.426 fps ts mono/SoE 13 (5) [-] none 14 4147200 B 511.286249 511.474301 4.637 fps ts mono/SoE 14 (6) [-] none 15 4147200 B 511.470542 511.674251 5.426 fps ts mono/SoE 15 (7) [-] none 16 4147200 B 511.672651 511.874337 4.948 fps ts mono/SoE 16 (0) [-] none 17 4147200 B 511.873988 512.074462 4.967 fps ts mono/SoE 17 (1) [-] none 18 4147200 B 512.075982 512.278296 4.951 fps ts mono/SoE 18 (2) [-] none 19 4147200 B 512.282631 512.482423 4.839 fps ts mono/SoE 19 (3) [-] none 20 4147200 B 518.986637 512.686333 0.149 fps ts mono/SoE 20 (4) [-] none 21 4147200 B 518.342709 512.886386 -1.553 fps ts mono/SoE 21 (5) [-] none 22 4147200 B 517.909812 513.090360 -2.310 fps ts mono/SoE 22 (6) [-] none 23 4147200 B 517.590775 513.294454 -3.134 fps ts mono/SoE 23 (7) [-] none 24 4147200 B 513.298465 513.494335 -0.233 fps ts mono/SoE 24 (0) [-] none 25 4147200 B 513.510273 513.698375 4.721 fps ts mono/SoE 25 (1) [-] none 26 4147200 B 513.698904 513.902327 5.301 fps ts mono/SoE 26 (2) [-] none 27 4147200 B 513.895971 514.102348 5.074 fps ts mono/SoE 27 (3) [-] none 28 4147200 B 514.099091 514.306337 4.923 fps ts mono/SoE 28 (4) [-] none 29 4147200 B 514.310348 514.510567 4.734 fps ts mono/SoE 29 (5) [-] none 30 4147200 B 514.509295 514.710367 5.026 fps ts mono/SoE 30 (6) [-] none 31 4147200 B 521.532513 514.914398 0.142 fps ts mono/SoE 31 (7) [-] none 32 4147200 B 520.885277 515.118385 -1.545 fps ts mono/SoE 32 (0) [-] none 33 4147200 B 520.411140 515.318336 -2.109 fps ts mono/SoE 33 (1) [-] none 34 4147200 B 515.325425 515.522278 -0.197 fps ts mono/SoE 34 (2) [-] none 35 4147200 B 515.538276 515.726423 4.698 fps ts mono/SoE 35 (3) [-] none 36 4147200 B 515.720767 515.930373 5.480 fps ts mono/SoE Cc: stable@vger.kernel.org Fixes: 66847ef013cc ("[media] uvcvideo: Add UVC timestamps support") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240610-hwtimestamp-followup-v1-2-f9eaed7be7f0@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 54f56ba4829a858729b0de9c61d85d1e3976dd64 Author: Jan Kara Date: Mon Jun 24 19:01:19 2024 +0200 jbd2: avoid infinite transaction commit loop commit 27ba5b67312a944576addc4df44ac3b709aabede upstream. Commit 9f356e5a4f12 ("jbd2: Account descriptor blocks into t_outstanding_credits") started to account descriptor blocks into transactions outstanding credits. However it didn't appropriately decrease the maximum amount of credits available to userspace. Thus if the filesystem requests a transaction smaller than j_max_transaction_buffers but large enough that when descriptor blocks are added the size exceeds j_max_transaction_buffers, we confuse add_transaction_credits() into thinking previous handles have grown the transaction too much and enter infinite journal commit loop in start_this_handle() -> add_transaction_credits() trying to create transaction with enough credits available. Fix the problem by properly accounting for transaction space reserved for descriptor blocks when verifying requested transaction handle size. CC: stable@vger.kernel.org Fixes: 9f356e5a4f12 ("jbd2: Account descriptor blocks into t_outstanding_credits") Reported-by: Alexander Coffin Link: https://lore.kernel.org/all/CA+hUFcuGs04JHZ_WzA1zGN57+ehL2qmHOt5a7RMpo+rv6Vyxtw@mail.gmail.com Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20240624170127.3253-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit ceee029e76dad479754eded4615b447e6124eda3 Author: Jan Kara Date: Mon Jun 24 19:01:18 2024 +0200 jbd2: precompute number of transaction descriptor blocks commit e3a00a23781c1f2fcda98a7aecaac515558e7a35 upstream. Instead of computing the number of descriptor blocks a transaction can have each time we need it (which is currently when starting each transaction but will become more frequent later) precompute the number once during journal initialization together with maximum transaction size. We perform the precomputation whenever journal feature set is updated similarly as for computation of journal->j_revoke_records_per_block. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20240624170127.3253-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 428f8371d09c31ad1317da23acd46e0837b909b6 Author: Jan Kara Date: Mon Jun 24 19:01:17 2024 +0200 jbd2: make jbd2_journal_get_max_txn_bufs() internal commit 4aa99c71e42ad60178c1154ec24e3df9c684fb67 upstream. There's no reason to have jbd2_journal_get_max_txn_bufs() public function. Currently all users are internal and can use journal->j_max_transaction_buffers instead. This saves some unnecessary recomputations of the limit as a bonus which becomes important as this function gets more complex in the following patch. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20240624170127.3253-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 5ab6ac4e9e165b0fe8a326308218337007224f05 Author: Harshit Mogalapalli Date: Tue May 14 02:50:38 2024 -0700 media: imx-pxp: Fix ERR_PTR dereference in pxp_probe() commit 57e9ce68ae98551da9c161aaab12b41fe8601856 upstream. devm_regmap_init_mmio() can fail, add a check and bail out in case of error. Fixes: 4e5bd3fdbeb3 ("media: imx-pxp: convert to regmap") Cc: stable@vger.kernel.org Signed-off-by: Harshit Mogalapalli Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240514095038.3464191-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit 7b17fbfe4fd6b8da85b345d819cdce6ed4ee1d24 Author: Tommaso Merciai Date: Mon Jun 10 10:10:34 2024 +0200 media: i2c: alvium: Move V4L2_CID_GAIN to V4L2_CID_ANALOG_GAIN commit a50a2a3242f35dd551d89a6bad17255a410ba955 upstream. Into alvium cameras REG_BCRM_GAIN_RW control the analog gain. Let's use the right V4L2_CID_ANALOGUE_GAIN ctrl. Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera") Cc: stable@vger.kernel.org Signed-off-by: Tommaso Merciai Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 08e5adac54e89972a4b76bddebc6ff6893290056 Author: Wentong Wu Date: Fri Jun 7 21:25:46 2024 +0800 media: ivsc: csi: add separate lock for v4l2 control handler commit c6be6471004e0e4d10d0514146d8c41550823d63 upstream. There're possibilities that privacy status change notification happens in the middle of the ongoing mei command which already takes the command lock, but v4l2_ctrl_s_ctrl() would also need the same lock prior to this patch, so this may results in circular locking problem. This patch adds one dedicated lock for v4l2 control handler to avoid described issue. Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule") Cc: stable@vger.kernel.org # for 6.6 and later Reported-by: Hao Yao Signed-off-by: Wentong Wu Tested-by: Jason Chen Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit ea916691a4b00a367ec949b74f3486dc923c789a Author: Javier Carrasco Date: Tue Jun 11 00:40:26 2024 +0200 leds: mt6360: Fix memory leak in mt6360_init_isnk_properties() commit e41d574b359ccd8d99be65c6f11502efa2b83136 upstream. The fwnode_for_each_child_node() loop requires manual intervention to decrement the child refcount in case of an early return. Add the missing calls to fwnode_handle_put(child) to avoid memory leaks in the error paths. Cc: stable@vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco Acked-by: Pavel Machek Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 8f4acacd20671777b9ae08411d50ca21a517e91f Author: Thomas Weißschuh Date: Thu Jun 13 17:24:51 2024 +0200 leds: triggers: Flush pending brightness before activating trigger commit ab477b766edd3bfb6321a6e3df4c790612613fae upstream. The race fixed in timer_trig_activate() between a blocking set_brightness() call and trigger->activate() can affect any trigger. So move the call to flush_work() into led_trigger_set() where it can avoid the race for all triggers. Fixes: 0db37915d912 ("leds: avoid races with workqueue") Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context") Cc: stable@vger.kernel.org Tested-by: Dustin L. Howett Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 5600d6013c634c2b6b6c6c55c8ecb50c3a6211f2 Author: Ofir Gal Date: Fri Jun 7 10:27:44 2024 +0300 md/md-bitmap: fix writing non bitmap pages commit ab99a87542f194f28e2364a42afbf9fb48b1c724 upstream. __write_sb_page() rounds up the io size to the optimal io size if it doesn't exceed the data offset, but it doesn't check the final size exceeds the bitmap length. For example: page count - 1 page size - 4K data offset - 1M optimal io size - 256K The final io size would be 256K (64 pages) but md_bitmap_storage_alloc() allocated 1 page, the IO would write 1 valid page and 63 pages that happens to be allocated afterwards. This leaks memory to the raid device superblock. This issue caused a data transfer failure in nvme-tcp. The network drivers checks the first page of an IO with sendpage_ok(), it returns true if the page isn't a slabpage and refcount >= 1. If the page !sendpage_ok() the network driver disables MSG_SPLICE_PAGES. As of now the network layer assumes all the pages of the IO are sendpage_ok() when MSG_SPLICE_PAGES is on. The bitmap pages aren't slab pages, the first page of the IO is sendpage_ok(), but the additional pages that happens to be allocated after the bitmap pages might be !sendpage_ok(). That cause skb_splice_from_iter() to stop the data transfer, in the case below it hangs 'mdadm --create'. The bug is reproducible, in order to reproduce we need nvme-over-tcp controllers with optimal IO size bigger than PAGE_SIZE. Creating a raid with bitmap over those devices reproduces the bug. In order to simulate large optimal IO size you can use dm-stripe with a single device. Script to reproduce the issue on top of brd devices using dm-stripe is attached below (will be added to blktest). I have added some logs to test the theory: ... md: created bitmap (1 pages) for device md127 __write_sb_page before md_super_write offset: 16, size: 262144. pfn: 0x53ee === __write_sb_page before md_super_write. logging pages === pfn: 0x53ee, slab: 0 <-- the only page that allocated for the bitmap pfn: 0x53ef, slab: 1 pfn: 0x53f0, slab: 0 pfn: 0x53f1, slab: 0 pfn: 0x53f2, slab: 0 pfn: 0x53f3, slab: 1 ... nvme_tcp: sendpage_ok - pfn: 0x53ee, len: 262144, offset: 0 skbuff: before sendpage_ok() - pfn: 0x53ee skbuff: before sendpage_ok() - pfn: 0x53ef WARNING at net/core/skbuff.c:6848 skb_splice_from_iter+0x142/0x450 skbuff: !sendpage_ok - pfn: 0x53ef. is_slab: 1, page_count: 1 ... Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Ofir Gal Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240607072748.3182199-1-ofir.gal@volumez.com Signed-off-by: Greg Kroah-Hartman commit e9ad5a675cba22b0a4ecb7632adf8d9c5dd72f7d Author: Ilpo Järvinen Date: Mon May 27 16:27:00 2024 +0300 leds: ss4200: Convert PCIBIOS_* return codes to errnos commit ce068e83976140badb19c7f1307926b4b562fac4 upstream. ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The error handling code assumes incorrectly it's a normal errno and checks for < 0. The return code is returned from the probe function as is but probe functions should return normal errnos. Remove < 0 from the check and convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: a328e95b82c1 ("leds: LED driver for Intel NAS SS4200 series (v5)") Cc: Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit fdcadf496f09eda221cca58b5cf13b405d1aba3f Author: Jay Buddhabhatti Date: Wed May 15 04:23:45 2024 -0700 drivers: soc: xilinx: check return status of get_api_version() commit 9b003e14801cf85a8cebeddc87bc9fc77100fdce upstream. Currently return status is not getting checked for get_api_version and because of that for x86 arch we are getting below smatch error. CC drivers/soc/xilinx/zynqmp_power.o drivers/soc/xilinx/zynqmp_power.c: In function 'zynqmp_pm_probe': drivers/soc/xilinx/zynqmp_power.c:295:12: warning: 'pm_api_version' is used uninitialized [-Wuninitialized] 295 | if (pm_api_version < ZYNQMP_PM_VERSION) | ^ CHECK drivers/soc/xilinx/zynqmp_power.c drivers/soc/xilinx/zynqmp_power.c:295 zynqmp_pm_probe() error: uninitialized symbol 'pm_api_version'. So, check return status of pm_get_api_version and return error in case of failure to avoid checking uninitialized pm_api_version variable. Fixes: b9b3a8be28b3 ("firmware: xilinx: Remove eemi ops for get_api_version") Signed-off-by: Jay Buddhabhatti Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240515112345.24673-1-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman commit 86d03934a5d612e56b4a7cc9c774fd4e7704ac7f Author: Javier Carrasco Date: Thu May 23 23:24:59 2024 +0200 cpufreq: qcom-nvmem: fix memory leaks in probe error paths commit d01c84b97f19f1137211e90b0a910289a560019e upstream. The code refactoring added new error paths between the np device node allocation and the call to of_node_put(), which leads to memory leaks if any of those errors occur. Add the missing of_node_put() in the error paths that require it. Cc: stable@vger.kernel.org Fixes: 57f2f8b4aa0c ("cpufreq: qcom: Refactor the driver to make it easier to extend") Signed-off-by: Javier Carrasco Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 02253054b4f96a4eb7c44379531c541e3e8e738c Author: Bitterblue Smith Date: Sun Jun 16 22:27:34 2024 +0300 wifi: rtw88: usb: Further limit the TX aggregation commit d7dd13ea54af8496aca2762a758d817d6813e81c upstream. Currently the number of frames sent to the chip in a single USB Request Block is limited only by the size of the TX buffer, which is 20 KiB. Testing reveals that as many as 13 frames get aggregated. This is more than what any of the chips would like to receive. RTL8822CU, RTL8822BU, and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame per URB. RTL8723DU in particular reliably malfunctions during a speed test if it receives more than 1 frame per URB. All traffic seems to stop. Pinging the AP no longer works. Fix this problem by limiting the number of frames sent to the chip in a single URB according to what each chip likes. Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames per URB. RTL8703B may or may not be found in USB devices. Declare that it wants only 1 frame per URB, just in case. Tested with RTL8723DU and RTL8811CU. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/cb46ea35-7e59-4742-9c1f-01ceeaad36fb@gmail.com Signed-off-by: Greg Kroah-Hartman commit 77911a765209de2792da4353a4dd8a8c2e3c664d Author: Bitterblue Smith Date: Mon Apr 29 20:57:52 2024 +0300 wifi: rtw88: usb: Fix disconnection after beacon loss commit 28818b4d871bc93cc4f5c7c7d7c526a6a096c09c upstream. When there is beacon loss, for example due to unrelated Bluetooth devices transmitting music nearby, the wifi connection dies soon after the first beacon loss message: Apr 28 20:47:14 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-BEACON-LOSS Apr 28 20:47:15 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 Apr 28 20:47:24 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-BEACON-LOSS Apr 28 20:47:25 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 Apr 28 20:47:34 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-BEACON-LOSS Apr 28 20:47:35 ideapad2 wpa_supplicant[1161]: wlp3s0f3u4: CTRL-EVENT-DISCONNECTED bssid=... reason=4 locally_generated=1 When the beacon loss happens, mac80211 makes rtw88 transmit a QOS NULL frame and asks to confirm the ACK status. Even though rtw88 confirms to mac80211 that the QOS NULL was transmitted successfully, the connection still dies. This is because rtw88 is handing the QOS NULL back to mac80211 with skb->data pointing to the headroom (the TX descriptor) instead of ieee80211_hdr. Fix the disconnection by moving skb->data to the correct position before ieee80211_tx_status_irqsafe(). The problem was observed with RTL8811AU (TP-Link Archer T2U Nano) and the potential future rtw88_8821au driver. Also tested with RTL8811CU (Tenda U9). Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith Signed-off-by: Ping-Ke Shih Link: https://msgid.link/ecbf0601-810d-4609-b8fc-8b0e38d2948d@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2d3673643a62d55d53176c97978e98bac8894820 Author: Po-Hao Huang Date: Fri May 17 09:33:50 2024 +0800 wifi: rtw89: fix HW scan not aborting properly commit 669b692247d4516e252c898c0e7366a09d84d1be upstream. There is a length limit on the commands we send to firmware, so dividing to two commands is sometimes required when scanning. When aborting scan, we should not send second scan command to firmware after the first one is finished. This could cause some unexpected errors when we cannot receive firmware events (e.g. in suspend). Another case is scan happens before suspending, ieee80211_do_stop() is called to abort scan and driver indicate scan completion by ieee80211_scan_completed(), which queues event to scan work. But scan work might be late to execute after ieee80211_do_stop(). To correct this, driver indicates ieee80211_scan_completed() before returning, so that ieee80211_do_stop() can flush scan work properly. Fixes: bcbefbd032df ("wifi: rtw89: add wait/completion for abort scan") Cc: stable@vger.kernel.org Co-developed-by: Chih-Kang Chang Signed-off-by: Chih-Kang Chang Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240517013350.11278-1-pkshih@realtek.com Signed-off-by: Greg Kroah-Hartman commit c2b75b4e483a14f8ab6d4cbc1dec39c1a95daa7d Author: Rafael Beims Date: Fri May 10 13:04:58 2024 +0200 wifi: mwifiex: Fix interface type change commit a17b9f590f6ec2b9f1b12b1db3bf1d181de6b272 upstream. When changing the interface type we also need to update the bss_num, the driver private data is searched based on a unique (bss_type, bss_num) tuple, therefore every time bss_type changes, bss_num must also change. This fixes for example an issue in which, after the mode changed, a wireless scan on the changed interface would not finish, leading to repeated -EBUSY messages to userspace when other scan requests were sent. Fixes: c606008b7062 ("mwifiex: Properly initialize private structure on interface type changes") Cc: stable@vger.kernel.org Signed-off-by: Rafael Beims Signed-off-by: Francesco Dolcini Signed-off-by: Kalle Valo Link: https://msgid.link/20240510110458.15475-1-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman commit a2fa4c058a7c1e9296c5de6cb86c33d795a13cd1 Author: Rafael J. Wysocki Date: Thu Jul 11 12:20:04 2024 +0200 genirq: Set IRQF_COND_ONESHOT in request_irq() commit c37927a203fa283950f6045602b9f71328ad786c upstream. The callers of request_irq() don't care about IRQF_ONESHOT because they don't provide threaded handlers, but if they happen to share the IRQ with the ACPI SCI, which has a threaded handler and sets IRQF_ONESHOT, request_irq() will fail for them due to a flags mismatch. Address this by making request_irq() add IRQF_COND_ONESHOT to the flags passed to request_threaded_irq() for all of its callers. Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") Reported-by: Stefan Seyfried Signed-off-by: Rafael J. Wysocki Signed-off-by: Thomas Gleixner Tested-by: Stefan Seyfried Cc: stable@vger.kerel.org Link: https://lore.kernel.org/r/5800834.DvuYhMxLoT@rjwysocki.net Closes: https://lore.kernel.org/lkml/205bd84a-fe8e-4963-968e-0763285f35ba@message-id.googlemail.com Signed-off-by: Greg Kroah-Hartman commit cf4a37d14ccd6e147d5c1e92ceb7c0fd131515f5 Author: levi.yun Date: Thu Jul 4 16:02:26 2024 +0100 trace/pid_list: Change gfp flags in pid_list_fill_irq() commit 7dc836187f7c6f70a82b4521503e9f9f96194581 upstream. pid_list_fill_irq() runs via irq_work. When CONFIG_PREEMPT_RT is disabled, it would run in irq_context. so it shouldn't sleep while memory allocation. Change gfp flags from GFP_KERNEL to GFP_NOWAIT to prevent sleep in irq_work. This change wouldn't impact functionality in practice because the worst-size is 2K. Cc: stable@goodmis.org Fixes: 8d6e90983ade2 ("tracing: Create a sparse bitmask for pid filtering") Link: https://lore.kernel.org/20240704150226.1359936-1-yeoreum.yun@arm.com Acked-by: Masami Hiramatsu (Google) Signed-off-by: levi.yun Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit c2ed4dd5e341d5b31b03e5be0f9d91cc806c3102 Author: Pavel Begunkov Date: Wed Jul 24 12:16:17 2024 +0100 io_uring: don't allow netpolling with SETUP_IOPOLL commit bd44d7e902c2b34c217d3b48874b079760ca7b6e upstream. IORING_SETUP_IOPOLL rings don't have any netpoll handling, let's fail attempts to register netpolling in this case, there might be people who will mix up IOPOLL and netpoll. Cc: stable@vger.kernel.org Fixes: ef1186c1a875b ("io_uring: add register/unregister napi function") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/1e7553aee0a8ae4edec6742cd6dd0c1e6914fba8.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4d909285f6d28083229729dd51323486bda4783a Author: Pavel Begunkov Date: Wed Jul 24 12:16:16 2024 +0100 io_uring: tighten task exit cancellations commit f8b632e89a101dae349a7b212c1771d7925f441b upstream. io_uring_cancel_generic() should retry if any state changes like a request is completed, however in case of a task exit it only goes for another loop and avoids schedule() if any tracked (i.e. REQ_F_INFLIGHT) request got completed. Let's assume we have a non-tracked request executing in iowq and a tracked request linked to it. Let's also assume io_uring_cancel_generic() fails to find and cancel the request, i.e. via io_run_local_work(), which may happen as io-wq has gaps. Next, the request logically completes, io-wq still hold a ref but queues it for completion via tw, which happens in io_uring_try_cancel_requests(). After, right before prepare_to_wait() io-wq puts the request, grabs the linked one and tries executes it, e.g. arms polling. Finally the cancellation loop calls prepare_to_wait(), there are no tw to run, no tracked request was completed, so the tctx_inflight() check passes and the task is put to indefinite sleep. Cc: stable@vger.kernel.org Fixes: 3f48cf18f886c ("io_uring: unify files and task cancel") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/acac7311f4e02ce3c43293f8f1fda9c705d158f1.1721819383.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 2a03e99ff9421d0be3a93a407b0f31748bed0312 Author: Pavel Begunkov Date: Tue Jul 16 19:05:46 2024 +0100 io_uring: fix lost getsockopt completions commit 24dce1c538a7ceac43f2f97aae8dfd4bb93ea9b9 upstream. There is a report that iowq executed getsockopt never completes. The reason being that io_uring_cmd_sock() can return a positive result, and io_uring_cmd() propagates it back to core io_uring, instead of IOU_OK. In case of io_wq_submit_work(), the request will be dropped without completing it. The offending code was introduced by a hack in a9c3eda7eada9 ("io_uring: fix submission-failure handling for uring-cmd"), however it was fine until getsockopt was introduced and started returning positive results. The right solution is to always return IOU_OK, since e0b23d9953b0c ("io_uring: optimise ltimeout for inline execution"), we should be able to do it without problems, however for the sake of backporting and minimising side effects, let's keep returning negative return codes and otherwise do IOU_OK. Link: https://github.com/axboe/liburing/issues/1181 Cc: stable@vger.kernel.org Fixes: 8e9fad0e70b7b ("io_uring: Add io_uring command support for sockets") Signed-off-by: Pavel Begunkov Reviewed-by: Breno Leitao Link: https://lore.kernel.org/r/ff349cf0654018189b6077e85feed935f0f8839e.1721149870.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 299bc6ffa57e04e74c6cce866d6c0741fb4897a1 Author: Baokun Li Date: Tue Jul 2 21:23:49 2024 +0800 ext4: make sure the first directory block is not a hole commit f9ca51596bbfd0f9c386dd1c613c394c78d9e5e6 upstream. The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported. After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash. Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad. Reported-by: syzbot+ae688d469e36fb5138d0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ae688d469e36fb5138d0 Fixes: 4e19d6b65fb4 ("ext4: allow directory holes") Cc: stable@kernel.org Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20240702132349.2600605-3-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit cdd345321699042ece4a9d2e70754d2397d378c5 Author: Baokun Li Date: Tue Jul 2 21:23:48 2024 +0800 ext4: check dot and dotdot of dx_root before making dir indexed commit 50ea741def587a64e08879ce6c6a30131f7111e7 upstream. Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue. Reported-by: syzbot+ae688d469e36fb5138d0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ae688d469e36fb5138d0 Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3") Cc: stable@kernel.org Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://patch.msgid.link/20240702132349.2600605-2-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 68afb02d219e60f283ea72bfdfd13c3db72db2df Author: Ming Lei Date: Thu Jun 20 11:06:31 2024 +0800 block: check bio alignment in blk_mq_submit_bio commit 0676c434a99be42f3bacca4adfd27df65edbf903 upstream. IO logical block size is one fundamental queue limit, and every IO has to be aligned with logical block size because our bio split can't deal with unaligned bio. The check has to be done with queue usage counter grabbed because device reconfiguration may change logical block size, and we can prevent the reconfiguration from happening by holding queue usage counter. logical_block_size stays in the 1st cache line of queue_limits, and this cache line is always fetched in fast path via bio_may_exceed_limits(), so IO perf won't be affected by this check. Cc: Yi Zhang Cc: Christoph Hellwig Cc: Ye Bin Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240620030631.3114026-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 550cc6a4dc25e3b63c5bc82db4abd069d6795f02 Author: Paolo Pisati Date: Sat Jun 1 17:32:54 2024 +0200 m68k: amiga: Turn off Warp1260 interrupts during boot commit 1d8491d3e726984343dd8c3cdbe2f2b47cfdd928 upstream. On an Amiga 1200 equipped with a Warp1260 accelerator, an interrupt storm coming from the accelerator board causes the machine to crash in local_irq_enable() or auto_irq_enable(). Disabling interrupts for the Warp1260 in amiga_parse_bootinfo() fixes the problem. Link: https://lore.kernel.org/r/ZkjwzVwYeQtyAPrL@amaterasu.local Cc: stable Signed-off-by: Paolo Pisati Reviewed-by: Michael Schmitz Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240601153254.186225-1-p.pisati@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 8ca170c39eca7cad6e0cfeb24e351d8f8eddcd65 Author: Jan Kara Date: Mon Jun 17 17:41:52 2024 +0200 udf: Avoid using corrupted block bitmap buffer commit a90d4471146de21745980cba51ce88e7926bcc4f upstream. When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not. Reported-by: syzbot+5f682cd029581f9edfd1@syzkaller.appspotmail.com CC: stable@vger.kernel.org Link: https://patch.msgid.link/20240617154201.29512-2-jack@suse.cz Fixes: 1e0d4adf17e7 ("udf: Check consistency of Space Bitmap Descriptor") Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit ed88f19eba21560302feb9f6d3916cbde8ea339b Author: Frederic Weisbecker Date: Fri Jun 21 11:15:59 2024 +0200 task_work: Introduce task_work_cancel() again commit f409530e4db9dd11b88cb7703c97c8f326ff6566 upstream. Re-introduce task_work_cancel(), this time to cancel an actual callback and not *any* callback pointing to a given function. This is going to be needed for perf events event freeing. Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-3-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit 012e110c7dc708f71eb718ad2e6ae77e19cf4769 Author: Frederic Weisbecker Date: Fri Jun 21 11:15:58 2024 +0200 task_work: s/task_work_cancel()/task_work_cancel_func()/ commit 68cbd415dd4b9c5b9df69f0f091879e56bf5907a upstream. A proper task_work_cancel() API that actually cancels a callback and not *any* callback pointing to a given function is going to be needed for perf events event freeing. Do the appropriate rename to prepare for that. Signed-off-by: Frederic Weisbecker Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-2-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit f8533c194141b6ebb0c0ccb1fbe3ac0f35cfdeeb Author: Steve French Date: Tue Jul 23 00:44:48 2024 -0500 cifs: mount with "unix" mount option for SMB1 incorrectly handled commit 0e314e452687ce0ec5874e42cdb993a34325d3d2 upstream. Although by default we negotiate CIFS Unix Extensions for SMB1 mounts to Samba (and they work if the user does not specify "unix" or "posix" or "linux" on mount), and we do properly handle when a user turns them off with "nounix" mount parm. But with the changes to the mount API we broke cases where the user explicitly specifies the "unix" option (or equivalently "linux" or "posix") on mount with vers=1.0 to Samba or other servers which support the CIFS Unix Extensions. "mount error(95): Operation not supported" and logged: "CIFS: VFS: Check vers= mount option. SMB3.11 disabled but required for POSIX extensions" even though CIFS Unix Extensions are supported for vers=1.0 This patch fixes the case where the user specifies both "unix" (or equivalently "posix" or "linux") and "vers=1.0" on mount to a server which supports the CIFS Unix Extensions. Cc: stable@vger.kernel.org Reviewed-by: David Howells Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 08e863bd579080a5c356fad9e0cd8f03de5c5b34 Author: Steve French Date: Mon Jul 22 23:40:08 2024 -0500 cifs: fix reconnect with SMB1 UNIX Extensions commit a214384ce26b6111ea8c8d58fa82a1ca63996c38 upstream. When mounting with the SMB1 Unix Extensions (e.g. mounts to Samba with vers=1.0), reconnects no longer reset the Unix Extensions (SetFSInfo SET_FILE_UNIX_BASIC) after tcon so most operations (e.g. stat, ls, open, statfs) will fail continuously with: "Operation not supported" if the connection ever resets (e.g. due to brief network disconnect) Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 3739d711246d8fbc95ff73dbdace9741cdce4777 Author: Steve French Date: Sun Jul 21 15:45:56 2024 -0500 cifs: fix potential null pointer use in destroy_workqueue in init_cifs error path commit 193cc89ea0ca1da311877d2b4bb5e9f03bcc82a2 upstream. Dan Carpenter reported a Smack static checker warning: fs/smb/client/cifsfs.c:1981 init_cifs() error: we previously assumed 'serverclose_wq' could be null (see line 1895) The patch which introduced the serverclose workqueue used the wrong oredering in error paths in init_cifs() for freeing it on errors. Fixes: 173217bd7336 ("smb3: retrying on failed server close") Cc: stable@vger.kernel.org Cc: Ritvik Budhiraja Reported-by: Dan Carpenter Reviewed-by: Dan Carpenter Reviewed-by: David Howells Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit fde89bb85457a5ad3b87739bf481a74972f236b0 Author: Fedor Pchelkin Date: Thu Feb 1 17:24:48 2024 +0300 apparmor: use kvfree_sensitive to free data->data commit 2bc73505a5cd2a18a7a542022722f136c19e3b87 upstream. Inside unpack_profile() data->data is allocated using kvmemdup() so it should be freed with the corresponding kvfree_sensitive(). Also add missing data->data release for rhashtable insertion failure path in unpack_profile(). Found by Linux Verification Center (linuxtesting.org). Fixes: e025be0f26d5 ("apparmor: support querying extended trusted helper extra data") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 185616085b12e651cdfd11ef00d1449f54552d89 Author: Sung Joon Kim Date: Mon Jul 8 19:29:49 2024 -0400 drm/amd/display: Check for NULL pointer commit 4ab68e168ae1695f7c04fae98930740aaf7c50fa upstream. [why & how] Need to make sure plane_state is initialized before accessing its members. Cc: Mario Limonciello Cc: Alex Deucher Cc: stable@vger.kernel.org Reviewed-by: Xi (Alex) Liu Signed-off-by: Sung Joon Kim Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher (cherry picked from commit 295d91cbc700651782a60572f83c24861607b648) Signed-off-by: Greg Kroah-Hartman commit 79bc42a9f5866e428dcf2e4659a20cc9b8e2492d Author: Shreyas Deodhar Date: Wed Jul 10 22:40:54 2024 +0530 scsi: qla2xxx: Fix optrom version displayed in FDMI commit 348744f27a35e087acc9378bf53537fbfb072775 upstream. Bios version was popluated for FDMI response. Systems with EFI would show optrom version as 0. EFI version is populated here and BIOS version is already displayed under FDMI_HBA_BOOT_BIOS_NAME. Cc: stable@vger.kernel.org Signed-off-by: Shreyas Deodhar Signed-off-by: Nilesh Javali Link: https://lore.kernel.org/r/20240710171057.35066-9-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5afbbe7a5535fd439d969c84014ec39b2c850d5d Author: Alex Deucher Date: Tue Jul 16 12:49:25 2024 -0400 drm/amd/display: fix corruption with high refresh rates on DCN 3.0 commit e3615bd198289f319172c428f20857accb46b830 upstream. This reverts commit bc87d666c05a13e6d4ae1ddce41fc43d2567b9a2 and the register changes from commit 6d4279cb99ac4f51d10409501d29969f687ac8dc. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3412 Cc: mikhail.v.gavrilov@gmail.com Cc: Rodrigo Siqueira Tested-by: Mikhail Gavrilov Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.10.x Signed-off-by: Greg Kroah-Hartman commit 475a5b3b7c8edf6e583a9eb59cf28ea770602e14 Author: Ma Ke Date: Tue Jul 9 17:20:11 2024 +0800 drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes commit 2df7aac81070987b0f052985856aa325a38debf6 upstream. In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 89c78134cc54 ("gma500: Add Poulsbo support") Signed-off-by: Ma Ke Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20240709092011.3204970-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit 977ee4fe895e1729cd36cc26916bbb10084713d6 Author: Ma Ke Date: Tue Jul 9 19:33:11 2024 +0800 drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes commit cb520c3f366c77e8d69e4e2e2781a8ce48d98e79 upstream. In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 6a227d5fd6c4 ("gma500: Add support for Cedarview") Signed-off-by: Ma Ke Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/20240709113311.37168-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman commit fc7c4b8ec9d64c971326743ac3b9460cc24dc5df Author: Pavel Begunkov Date: Wed Jul 10 18:58:17 2024 +0100 io_uring/io-wq: limit retrying worker initialisation commit 0453aad676ff99787124b9b3af4a5f59fbe808e2 upstream. If io-wq worker creation fails, we retry it by queueing up a task_work. tasK_work is needed because it should be done from the user process context. The problem is that retries are not limited, and if queueing a task_work is the reason for the failure, we might get into an infinite loop. It doesn't seem to happen now but it would with the following patch executing task_work in the freezer's loop. For now, arbitrarily limit the number of attempts to create a worker. Cc: stable@vger.kernel.org Fixes: 3146cba99aa28 ("io-wq: make worker creation resilient against signals") Reported-by: Julian Orth Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/8280436925db88448c7c85c6656edee1a43029ea.1720634146.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e71327a647a5879dd35fbbdb3bb0230a72f65e48 Author: Paul Moore Date: Thu May 2 17:57:51 2024 -0400 lsm: fixup the inode xattr capability handling commit 61df7b82820494368bd46071ca97e43a3dfc3b11 upstream. The current security_inode_setxattr() and security_inode_removexattr() hooks rely on individual LSMs to either call into the associated capability hooks (cap_inode_setxattr() or cap_inode_removexattr()), or return a magic value of 1 to indicate that the LSM layer itself should perform the capability checks. Unfortunately, with the default return value for these LSM hooks being 0, an individual LSM hook returning a 1 will cause the LSM hook processing to exit early, potentially skipping a LSM. Thankfully, with the exception of the BPF LSM, none of the LSMs which currently register inode xattr hooks should end up returning a value of 1, and in the BPF LSM case, with the BPF LSM hooks executing last there should be no real harm in stopping processing of the LSM hooks. However, the reliance on the individual LSMs to either call the capability hooks themselves, or signal the LSM with a return value of 1, is fragile and relies on a specific set of LSMs being enabled. This patch is an effort to resolve, or minimize, these issues. Before we discuss the solution, there are a few observations and considerations that we need to take into account: * BPF LSM registers an implementation for every LSM hook, and that implementation simply returns the hook's default return value, a 0 in this case. We want to ensure that the default BPF LSM behavior results in the capability checks being called. * SELinux and Smack do not expect the traditional capability checks to be applied to the xattrs that they "own". * SELinux and Smack are currently written in such a way that the xattr capability checks happen before any additional LSM specific access control checks. SELinux does apply SELinux specific access controls to all xattrs, even those not "owned" by SELinux. * IMA and EVM also register xattr hooks but assume that the LSM layer and specific LSMs have already authorized the basic xattr operation. In order to ensure we perform the capability based access controls before the individual LSM access controls, perform only one capability access control check for each operation, and clarify the logic around applying the capability controls, we need a mechanism to determine if any of the enabled LSMs "own" a particular xattr and want to take responsibility for controlling access to that xattr. The solution in this patch is to create a new LSM hook, 'inode_xattr_skipcap', that is not exported to the rest of the kernel via a security_XXX() function, but is used by the LSM layer to determine if a LSM wants to control access to a given xattr and avoid the traditional capability controls. Registering an inode_xattr_skipcap hook is optional, if a LSM declines to register an implementation, or uses an implementation that simply returns the default value (0), there is no effect as the LSM continues to enforce the capability based controls (unless another LSM takes ownership of the xattr). If none of the LSMs signal that the capability checks should be skipped, the capability check is performed and if access is granted the individual LSM xattr access control hooks are executed, keeping with the DAC-before-LSM convention. Cc: stable@vger.kernel.org Acked-by: Casey Schaufler Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 40d7f363196c1256f39d1abc58f9a3dfc2d955ec Author: Kory Maincent Date: Thu Jun 20 12:25:43 2024 +0200 media: i2c: Kconfig: Fix missing firmware upload config select commit fea074e97886b7ee2fe04a17bd60fd41723da1b7 upstream. FW_LOADER config only selects the firmware loader API, but we also need the sysfs_upload symbols for firmware_upload_unregister() and firmware_upload_register() to function properly. Fixes: 7a52ab415b43 ("media: i2c: Add driver for THine THP7312") Cc: stable@vger.kernel.org Signed-off-by: Kory Maincent Reviewed-by: Laurent Pinchart Reviewed-by: Paul Elder Link: https://lore.kernel.org/r/20240620102544.1918105-1-kory.maincent@bootlin.com Signed-off-by: Laurent Pinchart Signed-off-by: Greg Kroah-Hartman commit f1834feb25770d1c40f88d37d8a01b66be407db9 Author: Jan Kara Date: Mon Jun 24 17:12:56 2024 +0200 ext2: Verify bitmap and itable block numbers before using them commit 322a6aff03937aa1ece33b4e46c298eafaf9ac41 upstream. Verify bitmap block numbers and inode table blocks are sane before using them for checking bits in the block bitmap. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit d3493d6f0dfb1ab5225b62faa77732983f2187a1 Author: Chao Yu Date: Sun Jun 16 09:38:41 2024 +0800 hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode() commit 26a2ed107929a855155429b11e1293b83e6b2a8b upstream. Syzbot reports uninitialized value access issue as below: loop0: detected capacity change from 0 to 64 ===================================================== BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it. Cc: stable@vger.kernel.org Reported-by: syzbot+3ae6be33a50b5aae4dab@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-fsdevel/0000000000005ad04005ee48897f@google.com Signed-off-by: Chao Yu Link: https://lore.kernel.org/r/20240616013841.2217-1-chao@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit c7e2f43d182f5dde473389dbb39f16c9f0d64536 Author: Thomas Weißschuh Date: Tue Apr 2 23:10:34 2024 +0200 sysctl: always initialize i_uid/i_gid commit 98ca62ba9e2be5863c7d069f84f7166b45a5b2f4 upstream. Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed. Fixes: 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Signed-off-by: Joel Granados Signed-off-by: Greg Kroah-Hartman commit 1005f8300593edb6cdd6eda69ef061950269f7a1 Author: Igor Pylypiv Date: Tue Jul 2 02:47:31 2024 +0000 ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error commit 28ab9769117ca944cb6eb537af5599aa436287a4 upstream. SAT-5 revision 8 specification removed the text about the ANSI INCITS 431-2007 compliance which was requiring SCSI/ATA Translation (SAT) to return descriptor format sense data for the ATA PASS-THROUGH commands regardless of the setting of the D_SENSE bit. Let's honor the D_SENSE bit for ATA PASS-THROUGH commands while generating the "ATA PASS-THROUGH INFORMATION AVAILABLE" sense data. SAT-5 revision 7 ================ 12.2.2.8 Fixed format sense data Table 212 shows the fields returned in the fixed format sense data (see SPC-5) for ATA PASS-THROUGH commands. SATLs compliant with ANSI INCITS 431-2007, SCSI/ATA Translation (SAT) return descriptor format sense data for the ATA PASS-THROUGH commands regardless of the setting of the D_SENSE bit. SAT-5 revision 8 ================ 12.2.2.8 Fixed format sense data Table 211 shows the fields returned in the fixed format sense data (see SPC-5) for ATA PASS-THROUGH commands. Cc: stable@vger.kernel.org # 4.19+ Reported-by: Niklas Cassel Closes: https://lore.kernel.org/linux-ide/Zn1WUhmLglM4iais@ryzen.lan Reviewed-by: Niklas Cassel Signed-off-by: Igor Pylypiv Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20240702024735.1152293-4-ipylypiv@google.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 67d9d0b6ae4aaf2c4cef103a96a145c7fdfb15f8 Author: Igor Pylypiv Date: Tue Jul 2 02:47:30 2024 +0000 ata: libata-scsi: Do not overwrite valid sense data when CK_COND=1 commit 97981926224afe17ba3e22e0c2b7dd8b516ee574 upstream. Current ata_gen_passthru_sense() code performs two actions: 1. Generates sense data based on the ATA 'status' and ATA 'error' fields. 2. Populates "ATA Status Return sense data descriptor" / "Fixed format sense data" with ATA taskfile fields. The problem is that #1 generates sense data even when a valid sense data is already present (ATA_QCFLAG_SENSE_VALID is set). Factoring out #2 into a separate function allows us to generate sense data only when there is no valid sense data (ATA_QCFLAG_SENSE_VALID is not set). As a bonus, we can now delete a FIXME comment in atapi_qc_complete() which states that we don't want to translate taskfile registers into sense descriptors for ATAPI. Additionally, always set SAM_STAT_CHECK_CONDITION when CK_COND=1 because SAT specification mandates that SATL shall return CHECK CONDITION if the CK_COND bit is set. The ATA PASS-THROUGH handling logic in ata_scsi_qc_complete() is hard to read/understand. Improve the readability of the code by moving checks into self-explanatory boolean variables. Cc: stable@vger.kernel.org # 4.19+ Co-developed-by: Niklas Cassel Reviewed-by: Hannes Reinecke Reviewed-by: Damien Le Moal Reviewed-by: Niklas Cassel Signed-off-by: Igor Pylypiv Link: https://lore.kernel.org/r/20240702024735.1152293-3-ipylypiv@google.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 6a96041659e834dc0b172dda4b2df512d63920c2 Author: Dikshita Agarwal Date: Thu May 9 10:44:29 2024 +0530 media: venus: fix use after free in vdec_close commit a0157b5aa34eb43ec4c5510f9c260bbb03be937e upstream. There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. Cc: stable@vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Dikshita Agarwal Acked-by: Vikash Garodia Signed-off-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9e0ad66cc78ddab6bfd10adcd5c9e98cce10c668 Author: Joe Hattori Date: Thu Jun 27 15:31:09 2024 +0900 char: tpm: Fix possible memory leak in tpm_bios_measurements_open() commit 5d8e2971e817bb64225fc0b6327a78752f58a9aa upstream. In tpm_bios_measurements_open(), get_device() is called on the device embedded in struct tpm_chip. In the error path, however, put_device() is not called. This results in a reference count leak, which prevents the device from being properly released. This commit makes sure to call put_device() when the seq_open() call fails. Cc: stable@vger.kernel.org # +v4.18 Fixes: 9b01b5356629 ("tpm: Move shared eventlog functions to common.c") Signed-off-by: Joe Hattori Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d7f3e486b8f030d0448fb87e474e389be8655832 Author: Vitor Soares Date: Fri Jun 21 10:50:45 2024 +0100 tpm_tis_spi: add missing attpm20p SPI device ID entry commit 0543f29408a151c1c4a12e5da07ec45c2779b9b8 upstream. "atmel,attpm20p" DT compatible is missing its SPI device ID entry, not allowing module autoloading and leading to the following message: "SPI driver tpm_tis_spi has no spi_device_id for atmel,attpm20p" Based on: commit 7eba41fe8c7b ("tpm_tis_spi: Add missing SPI ID") Fix this by adding the corresponding "attpm20p" spi_device_id entry. Fixes: 3c45308c44ed ("tpm_tis_spi: Add compatible string atmel,attpm20p") Cc: stable@vger.kernel.org # +v6.9 Signed-off-by: Vitor Soares Reviewed-by: Lukas Wunner Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 9291f9de77e10e3fb10be8eadaba0a9235eec551 Author: Thomas Weißschuh Date: Mon May 27 18:15:58 2024 +0200 selftests/nolibc: fix printf format mismatch in expect_str_buf_eq() commit 92098b1c10cb29bcc6fa0908a766dc9e16b1e889 upstream. Fix the following compiler warning on 32bit: i386-linux-gcc -Os -fno-ident -fno-asynchronous-unwind-tables -std=c89 -W -Wall -Wextra -fno-stack-protector -m32 -mstack-protector-guard=global -fstack-protector-all -o nolibc-test \ -nostdlib -nostdinc -static -Isysroot/i386/include nolibc-test.c nolibc-test-linkage.c -lgcc nolibc-test.c: In function 'expect_str_buf_eq': nolibc-test.c:610:30: error: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Werror=format=] 610 | llen += printf(" = %lu <%s> ", expr, buf); | ~~^ ~~~~ | | | | | size_t {aka unsigned int} | long unsigned int | %u Fixes: 1063649cf531 ("selftests/nolibc: Add tests for strlcat() and strlcpy()") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Signed-off-by: Greg Kroah-Hartman commit 1477bafd7df4f0062486c518d2266463d98ea614 Author: Igor Pylypiv Date: Tue Jul 2 02:47:29 2024 +0000 ata: libata-scsi: Fix offsets for the fixed format sense data commit 38dab832c3f4154968f95b267a3bb789e87554b0 upstream. Correct the ATA PASS-THROUGH fixed format sense data offsets to conform to SPC-6 and SAT-5 specifications. Additionally, set the VALID bit to indicate that the INFORMATION field contains valid information. INFORMATION =========== SAT-5 Table 212 — "Fixed format sense data INFORMATION field for the ATA PASS-THROUGH commands" defines the following format: +------+------------+ | Byte | Field | +------+------------+ | 0 | ERROR | | 1 | STATUS | | 2 | DEVICE | | 3 | COUNT(7:0) | +------+------------+ SPC-6 Table 48 - "Fixed format sense data" specifies that the INFORMATION field starts at byte 3 in sense buffer resulting in the following offsets for the ATA PASS-THROUGH commands: +------------+-------------------------+ | Field | Offset in sense buffer | +------------+-------------------------+ | ERROR | 3 | | STATUS | 4 | | DEVICE | 5 | | COUNT(7:0) | 6 | +------------+-------------------------+ COMMAND-SPECIFIC INFORMATION ============================ SAT-5 Table 213 - "Fixed format sense data COMMAND-SPECIFIC INFORMATION field for ATA PASS-THROUGH" defines the following format: +------+-------------------+ | Byte | Field | +------+-------------------+ | 0 | FLAGS | LOG INDEX | | 1 | LBA (7:0) | | 2 | LBA (15:8) | | 3 | LBA (23:16) | +------+-------------------+ SPC-6 Table 48 - "Fixed format sense data" specifies that the COMMAND-SPECIFIC-INFORMATION field starts at byte 8 in sense buffer resulting in the following offsets for the ATA PASS-THROUGH commands: Offsets of these fields in the fixed sense format are as follows: +-------------------+-------------------------+ | Field | Offset in sense buffer | +-------------------+-------------------------+ | FLAGS | LOG INDEX | 8 | | LBA (7:0) | 9 | | LBA (15:8) | 10 | | LBA (23:16) | 11 | +-------------------+-------------------------+ Reported-by: Akshat Jain Fixes: 11093cb1ef56 ("libata-scsi: generate correct ATA pass-through sense") Cc: stable@vger.kernel.org Reviewed-by: Hannes Reinecke Reviewed-by: Niklas Cassel Signed-off-by: Igor Pylypiv Link: https://lore.kernel.org/r/20240702024735.1152293-2-ipylypiv@google.com Signed-off-by: Niklas Cassel Signed-off-by: Greg Kroah-Hartman commit 4a534f9550215e2eb00cef390755f1645e664c1d Author: Damien Le Moal Date: Tue Jul 2 16:32:34 2024 +0900 null_blk: Fix description of the fua parameter commit 1c0b3fca381bf879e2168b362692f83808677f95 upstream. The description of the fua module parameter is defined using MODULE_PARM_DESC() with the first argument passed being "zoned". That is the wrong name, obviously. Fix that by using the correct "fua" parameter name so that "modinfo null_blk" displays correct information. Fixes: f4f84586c8b9 ("null_blk: Introduce fua attribute") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20240702073234.206458-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d2abd36ce8b7dc5f066aa28bd7a89db7c1944d4c Author: Alain Volmat Date: Wed Jul 3 13:59:16 2024 +0200 media: stm32: dcmipp: correct error handling in dcmipp_create_subdevs commit a7351f0d3668b449fdc2cfd90403b1cb1f03ed6d upstream. Correct error handling within the dcmipp_create_subdevs by properly decrementing the i counter when releasing the subdevs. Fixes: 28e0f3772296 ("media: stm32-dcmipp: STM32 DCMIPP camera interface driver") Cc: stable@vger.kernel.org Signed-off-by: Alain Volmat Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus [hverkuil: correct the indices: it's [i], not [i - 1].] Signed-off-by: Greg Kroah-Hartman commit e20f9e50dced0229d6cb4d60d4885172421250aa Author: Yu Kuai Date: Sat Jun 15 16:51:43 2024 +0800 md/raid5: fix spares errors about rcu usage commit 2314c2e3a70521f055dd011245dccf6fd97c7ee0 upstream. As commit ad8606702f26 ("md/raid5: remove rcu protection to access rdev from conf") explains, rcu protection can be removed, however, there are three places left, there won't be any real problems. drivers/md/raid5.c:8071:24: error: incompatible types in comparison expression (different address spaces): drivers/md/raid5.c:8071:24: struct md_rdev [noderef] __rcu * drivers/md/raid5.c:8071:24: struct md_rdev * drivers/md/raid5.c:7569:25: error: incompatible types in comparison expression (different address spaces): drivers/md/raid5.c:7569:25: struct md_rdev [noderef] __rcu * drivers/md/raid5.c:7569:25: struct md_rdev * drivers/md/raid5.c:7573:25: error: incompatible types in comparison expression (different address spaces): drivers/md/raid5.c:7573:25: struct md_rdev [noderef] __rcu * drivers/md/raid5.c:7573:25: struct md_rdev * Fixes: ad8606702f26 ("md/raid5: remove rcu protection to access rdev from conf") Cc: stable@vger.kernel.org Signed-off-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240615085143.1648223-1-yukuai1@huaweicloud.com Signed-off-by: Greg Kroah-Hartman commit 794964ac11ffe6ceeea7510d88afee3dfd50ee1b Author: Eric Sandeen Date: Tue Jul 2 17:22:41 2024 -0500 fuse: verify {g,u}id mount options correctly commit 525bd65aa759ec320af1dc06e114ed69733e9e23 upstream. As was done in 0200679fc795 ("tmpfs: verify {g,u}id mount options correctly") we need to validate that the requested uid and/or gid is representable in the filesystem's idmapping. Cribbing from the above commit log, The contract for {g,u}id mount options and {g,u}id values in general set from userspace has always been that they are translated according to the caller's idmapping. In so far, fuse has been doing the correct thing. But since fuse is mountable in unprivileged contexts it is also necessary to verify that the resulting {k,g}uid is representable in the namespace of the superblock. Fixes: c30da2e981a7 ("fuse: convert to use the new mount API") Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/8f07d45d-c806-484d-a2e3-7a2199df1cd2@redhat.com Reviewed-by: Christian Brauner Reviewed-by: Josef Bacik Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit 054dc05f57694d9e1d22cccee268adb3a6ebc6ff Author: Tejun Heo Date: Tue Jun 25 15:29:58 2024 -1000 sched/fair: set_load_weight() must also call reweight_task() for SCHED_IDLE tasks commit d329605287020c3d1c3b0dadc63d8208e7251382 upstream. When a task's weight is being changed, set_load_weight() is called with @update_load set. As weight changes aren't trivial for the fair class, set_load_weight() calls fair.c::reweight_task() for fair class tasks. However, set_load_weight() first tests task_has_idle_policy() on entry and skips calling reweight_task() for SCHED_IDLE tasks. This is buggy as SCHED_IDLE tasks are just fair tasks with a very low weight and they would incorrectly skip load, vlag and position updates. Fix it by updating reweight_task() to take struct load_weight as idle weight can't be expressed with prio and making set_load_weight() call reweight_task() for SCHED_IDLE tasks too when @update_load is set. Fixes: 9059393e4ec1 ("sched/fair: Use reweight_entity() for set_user_nice()") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Tejun Heo Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org # v4.15+ Link: http://lkml.kernel.org/r/20240624102331.GI31592@noisy.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit f035d08e8ce2de65d9279045347113daf8490b24 Author: Zong-Zhe Yang Date: Tue Jul 9 15:35:31 2024 +0800 wifi: mac80211: chanctx emulation set CHANGE_CHANNEL when in_reconfig commit 19b815ed71aadee9a2d31b7a700ef61ae8048010 upstream. Chanctx emulation didn't info IEEE80211_CONF_CHANGE_CHANNEL to drivers during ieee80211_restart_hw (ieee80211_emulate_add_chanctx). It caused non-chanctx drivers to not stand on the correct channel after recovery. RX then behaved abnormally. Finally, disconnection/reconnection occurred. So, set IEEE80211_CONF_CHANGE_CHANNEL when in_reconfig. Signed-off-by: Zong-Zhe Yang Link: https://patch.msgid.link/20240709073531.30565-1-kevin_yang@realtek.com Cc: stable@vger.kernel.org Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2dd958fa9f31ff5912391846e4eecb07c8aadaff Author: Chuck Lever Date: Tue Jun 11 15:36:46 2024 -0400 NFSD: Support write delegations in LAYOUTGET commit abc02e5602f7bf9bbae1e8999570a2ad5114578c upstream. I noticed LAYOUTGET(LAYOUTIOMODE4_RW) returning NFS4ERR_ACCESS unexpectedly. The NFS client had created a file with mode 0444, and the server had returned a write delegation on the OPEN(CREATE). The client was requesting a RW layout using the write delegation stateid so that it could flush file modifications. Creating a read-only file does not seem to be problematic for NFSv4.1 without pNFS, so I began looking at NFSD's implementation of LAYOUTGET. The failure was because fh_verify() was doing a permission check as part of verifying the FH presented during the LAYOUTGET. It uses the loga_iomode value to specify the @accmode argument to fh_verify(). fh_verify(MAY_WRITE) on a file whose mode is 0444 fails with -EACCES. To permit LAYOUT* operations in this case, add OWNER_OVERRIDE when checking the access permission of the incoming file handle for LAYOUTGET and LAYOUTCOMMIT. Cc: Christoph Hellwig Cc: stable@vger.kernel.org # v6.6+ Message-Id: 4E9C0D74-A06D-4DC3-A48A-73034DC40395@oracle.com Reviewed-by: Jeff Layton Reviewed-by: Christoph Hellwig Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8bb69cbc32d69e876bb13f40d9a93c927e2b42bf Author: Thomas Hellström Date: Fri Jul 5 15:28:28 2024 +0200 drm/xe: Use write-back caching mode for system memory on DGFX commit 5207c393d3e7dda9aff813d6b3e2264370d241be upstream. The caching mode for buffer objects with VRAM as a possible placement was forced to write-combined, regardless of placement. However, write-combined system memory is expensive to allocate and even though it is pooled, the pool is expensive to shrink, since it involves global CPU TLB flushes. Moreover write-combined system memory from TTM is only reliably available on x86 and DGFX doesn't have an x86 restriction. So regardless of the cpu caching mode selected for a bo, internally use write-back caching mode for system memory on DGFX. Coherency is maintained, but user-space clients may perceive a difference in cpu access speeds. v2: - Update RB- and Ack tags. - Rephrase wording in xe_drm.h (Matt Roper) v3: - Really rephrase wording. Signed-off-by: Thomas Hellström Fixes: 622f709ca629 ("drm/xe/uapi: Add support for CPU caching mode") Cc: Pallavi Mishra Cc: Matthew Auld Cc: dri-devel@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Effie Yu Cc: Matthew Brost Cc: Maarten Lankhorst Cc: Jose Souza Cc: Michal Mrozek Cc: # v6.8+ Acked-by: Matthew Auld Acked-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi Fixes: 622f709ca629 ("drm/xe/uapi: Add support for CPU caching mode") Acked-by: Michal Mrozek Acked-by: Effie Yu #On chat Link: https://patchwork.freedesktop.org/patch/msgid/20240705132828.27714-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 01e0cfc994be484ddcb9e121e353e51d8bb837c0) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman commit e1523d1372339e8b017e57bb4a8e9b84d728cb01 Author: Nicolas Dichtel Date: Wed Jul 10 10:14:29 2024 +0200 ipv6: take care of scope when choosing the src addr commit abb9a68d2c64dd9b128ae1f2e635e4d805e7ce64 upstream. When the source address is selected, the scope must be checked. For example, if a loopback address is assigned to the vrf device, it must not be chosen for packets sent outside. CC: stable@vger.kernel.org Fixes: afbac6010aec ("net: ipv6: Address selection needs to consider L3 domains") Signed-off-by: Nicolas Dichtel Reviewed-by: David Ahern Link: https://patch.msgid.link/20240710081521.3809742-4-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a9e9686a84fac8f42a9210efe866edc87bdda8b4 Author: Nicolas Dichtel Date: Wed Jul 10 10:14:27 2024 +0200 ipv4: fix source address selection with route leak commit 6807352353561187a718e87204458999dbcbba1b upstream. By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address. Let's add a check against the output interface and call the appropriate function to select the source address. CC: stable@vger.kernel.org Fixes: 8cbb512c923d ("net: Add source address lookup op for VRF") Signed-off-by: Nicolas Dichtel Reviewed-by: David Ahern Link: https://patch.msgid.link/20240710081521.3809742-2-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ce1268b5adbe2fec354aede0e00098e97e987aa4 Author: Nicolas Dichtel Date: Wed Jul 10 10:14:28 2024 +0200 ipv6: fix source address selection with route leak commit 252442f2ae317d109ef0b4b39ce0608c09563042 upstream. By default, an address assigned to the output interface is selected when the source address is not specified. This is problematic when a route, configured in a vrf, uses an interface from another vrf (aka route leak). The original vrf does not own the selected source address. Let's add a check against the output interface and call the appropriate function to select the source address. CC: stable@vger.kernel.org Fixes: 0d240e7811c4 ("net: vrf: Implement get_saddr for IPv6") Signed-off-by: Nicolas Dichtel Link: https://patch.msgid.link/20240710081521.3809742-3-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ebb124228eb572452926e07f3a4bbf1165f009ae Author: Pavel Begunkov Date: Wed Jul 10 18:58:18 2024 +0100 kernel: rerun task_work while freezing in get_signal() commit 943ad0b62e3c21f324c4884caa6cb4a871bca05c upstream. io_uring can asynchronously add a task_work while the task is getting freezed. TIF_NOTIFY_SIGNAL will prevent the task from sleeping in do_freezer_trap(), and since the get_signal()'s relock loop doesn't retry task_work, the task will spin there not being able to sleep until the freezing is cancelled / the task is killed / etc. Run task_works in the freezer path. Keep the patch small and simple so it can be easily back ported, but we might need to do some cleaning after and look if there are other places with similar problems. Cc: stable@vger.kernel.org Link: https://github.com/systemd/systemd/issues/33626 Fixes: 12db8b690010c ("entry: Add support for TIF_NOTIFY_SIGNAL") Reported-by: Julian Orth Acked-by: Oleg Nesterov Acked-by: Tejun Heo Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/89ed3a52933370deaaf61a0a620a6ac91f1e754d.1720634146.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b7859ff398b6b656e1689daa860eb34837b4bb89 Author: Filipe Manana Date: Thu Jul 4 16:11:20 2024 +0100 btrfs: fix extent map use-after-free when adding pages to compressed bio commit 8e7860543a94784d744c7ce34b78a2e11beefa5c upstream. At add_ra_bio_pages() we are accessing the extent map to calculate 'add_size' after we dropped our reference on the extent map, resulting in a use-after-free. Fix this by computing 'add_size' before dropping our extent map reference. Reported-by: syzbot+853d80cba98ce1157ae6@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/000000000000038144061c6d18f2@google.com/ Fixes: 6a4049102055 ("btrfs: subpage: make add_ra_bio_pages() compatible") CC: stable@vger.kernel.org # 6.1+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit bf55c43fcf4364d8a2b5ecf290f23e018767fc82 Author: Lai Jiangshan Date: Wed Jul 3 17:27:41 2024 +0800 workqueue: Always queue work items to the newest PWQ for order workqueues commit 58629d4871e8eb2c385b16a73a8451669db59f39 upstream. To ensure non-reentrancy, __queue_work() attempts to enqueue a work item to the pool of the currently executing worker. This is not only unnecessary for an ordered workqueue, where order inherently suggests non-reentrancy, but it could also disrupt the sequence if the item is not enqueued on the newest PWQ. Just queue it to the newest PWQ and let order management guarantees non-reentrancy. Signed-off-by: Lai Jiangshan Fixes: 4c065dbce1e8 ("workqueue: Enable unbound cpumask update on ordered workqueues") Cc: stable@vger.kernel.org # v6.9+ Signed-off-by: Tejun Heo (cherry picked from commit 74347be3edfd11277799242766edf844c43dd5d3) Signed-off-by: Greg Kroah-Hartman commit 66f23a7b5174b5d3e7111fd2d0d5a4f3faaa12e5 Author: Chengen Du Date: Sat Jul 13 19:47:35 2024 +0800 af_packet: Handle outgoing VLAN packets without hardware offloading commit 79eecf631c14e7f4057186570ac20e2cfac3802e upstream. The issue initially stems from libpcap. The ethertype will be overwritten as the VLAN TPID if the network interface lacks hardware VLAN offloading. In the outbound packet path, if hardware VLAN offloading is unavailable, the VLAN tag is inserted into the payload but then cleared from the sk_buff struct. Consequently, this can lead to a false negative when checking for the presence of a VLAN tag, causing the packet sniffing outcome to lack VLAN tag information (i.e., TCI-TPID). As a result, the packet capturing tool may be unable to parse packets as expected. The TCI-TPID is missing because the prb_fill_vlan_info() function does not modify the tp_vlan_tci/tp_vlan_tpid values, as the information is in the payload and not in the sk_buff struct. The skb_vlan_tag_present() function only checks vlan_all in the sk_buff struct. In cooked mode, the L2 header is stripped, preventing the packet capturing tool from determining the correct TCI-TPID value. Additionally, the protocol in SLL is incorrect, which means the packet capturing tool cannot parse the L3 header correctly. Link: https://github.com/the-tcpdump-group/libpcap/issues/1105 Link: https://lore.kernel.org/netdev/20240520070348.26725-1-chengen.du@canonical.com/T/#u Fixes: 393e52e33c6c ("packet: deliver VLAN TCI to userspace") Cc: stable@vger.kernel.org Signed-off-by: Chengen Du Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20240713114735.62360-1-chengen.du@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c18191ae468fcb31a3866a3f2029b866d0835a9f Author: Breno Leitao Date: Fri Jul 12 07:34:15 2024 -0700 net: netconsole: Disable target before netpoll cleanup commit 97d9fba9a812cada5484667a46e14a4c976ca330 upstream. Currently, netconsole cleans up the netpoll structure before disabling the target. This approach can lead to race conditions, as message senders (write_ext_msg() and write_msg()) check if the target is enabled before using netpoll. The sender can validate that the target is enabled, but, the netpoll might be de-allocated already, causing undesired behaviours. This patch reverses the order of operations: 1. Disable the target 2. Clean up the netpoll structure This change eliminates the potential race condition, ensuring that no messages are sent through a partially cleaned-up netpoll structure. Fixes: 2382b15bcc39 ("netconsole: take care of NETDEV_UNREGISTER event") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20240712143415.1141039-1-leitao@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2cdab4b4bf77369961f706cdeb7d040db10c5217 Author: Yu Liao Date: Thu Jul 11 20:48:43 2024 +0800 tick/broadcast: Make takeover of broadcast hrtimer reliable commit f7d43dd206e7e18c182f200e67a8db8c209907fa upstream. Running the LTP hotplug stress test on a aarch64 machine results in rcu_sched stall warnings when the broadcast hrtimer was owned by the un-plugged CPU. The issue is the following: CPU1 (owns the broadcast hrtimer) CPU2 tick_broadcast_enter() // shutdown local timer device broadcast_shutdown_local() ... tick_broadcast_exit() clockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT) // timer device is not programmed cpumask_set_cpu(cpu, tick_broadcast_force_mask) initiates offlining of CPU1 take_cpu_down() /* * CPU1 shuts down and does not * send broadcast IPI anymore */ takedown_cpu() hotplug_cpu__broadcast_tick_pull() // move broadcast hrtimer to this CPU clockevents_program_event() bc_set_next() hrtimer_start() /* * timer device is not programmed * because only the first expiring * timer will trigger clockevent * device reprogramming */ What happens is that CPU2 exits broadcast mode with force bit set, then the local timer device is not reprogrammed and CPU2 expects to receive the expired event by the broadcast IPI. But this does not happen because CPU1 is offlined by CPU2. CPU switches the clockevent device to ONESHOT state, but does not reprogram the device. The subsequent reprogramming of the hrtimer broadcast device does not program the clockevent device of CPU2 either because the pending expiry time is already in the past and the CPU expects the event to be delivered. As a consequence all CPUs which wait for a broadcast event to be delivered are stuck forever. Fix this issue by reprogramming the local timer device if the broadcast force bit of the CPU is set so that the broadcast hrtimer is delivered. [ tglx: Massage comment and change log. Add Fixes tag ] Fixes: 989dcb645ca7 ("tick: Handle broadcast wakeup of multiple cpus") Signed-off-by: Yu Liao Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240711124843.64167-1-liaoyu15@huawei.com Signed-off-by: Greg Kroah-Hartman commit 4eb577144b6f6f483a74d8986c85e0ac2f35b0a4 Author: Krzysztof Kozlowski Date: Tue Jul 2 16:52:48 2024 +0200 dt-bindings: thermal: correct thermal zone node name limit commit 97e32381d0fc6c2602a767b0c46e15eb2b75971d upstream. Linux kernel uses thermal zone node name during registering thermal zones and has a hard-coded limit of 20 characters, including terminating NUL byte. The bindings expect node names to finish with '-thermal' which is eight bytes long, thus we have only 11 characters for the reset of the node name (thus 10 for the pattern after leading fixed character). Reported-by: Rob Herring Closes: https://lore.kernel.org/all/CAL_JsqKogbT_4DPd1n94xqeHaU_J8ve5K09WOyVsRX3jxxUW3w@mail.gmail.com/ Fixes: 1202a442a31f ("dt-bindings: thermal: Add yaml bindings for thermal zones") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240702145248.47184-1-krzysztof.kozlowski@linaro.org Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 1535254fa4b38620d01535a99576f34c24d68710 Author: Krzysztof Kozlowski Date: Tue Jul 9 14:59:31 2024 +0200 thermal/drivers/broadcom: Fix race between removal and clock disable commit e90c369cc2ffcf7145a46448de101f715a1f5584 upstream. During the probe, driver enables clocks necessary to access registers (in get_temp()) and then registers thermal zone with managed-resources (devm) interface. Removal of device is not done in reversed order, because: 1. Clock will be disabled in driver remove() callback - thermal zone is still registered and accessible to users, 2. devm interface will unregister thermal zone. This leaves short window between (1) and (2) for accessing the get_temp() callback with disabled clock. Fix this by enabling clock also via devm-interface, so entire cleanup path will be in proper, reversed order. Fixes: 8454c8c09c77 ("thermal/drivers/bcm2835: Remove buggy call to thermal_of_zone_unregister") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240709-thermal-probe-v1-1-241644e2b6e0@linaro.org Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 1d1970493c289e3f44b9ec847ed26a5dbdf56a62 Author: Sungjong Seo Date: Fri May 31 19:14:44 2024 +0900 exfat: fix potential deadlock on __exfat_get_dentry_set commit 89fc548767a2155231128cb98726d6d2ea1256c9 upstream. When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS. Fixes: a3ff29a95fde ("exfat: support dynamic allocate bh for exfat_entry_set_cache") Cc: stable@vger.kernel.org # v6.2+ Reported-by: syzbot+412a392a2cd4a65e71db@syzkaller.appspotmail.com Closes: https://lore.kernel.org/lkml/000000000000fef47e0618c0327f@google.com Signed-off-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 4615095f17abba1e8ed029ff8e59fd10ba916102 Author: Takashi Sakamoto Date: Fri Jul 26 01:16:48 2024 +0900 Revert "firewire: Annotate struct fw_iso_packet with __counted_by()" commit 00e3913b0416fe69d28745c0a2a340e2f76c219c upstream. This reverts commit d3155742db89df3b3c96da383c400e6ff4d23c25. The header_length field is byte unit, thus it can not express the number of elements in header field. It seems that the argument for counted_by attribute can have no arithmetic expression, therefore this commit just reverts the issued commit. Suggested-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/20240725161648.130404-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto Signed-off-by: Greg Kroah-Hartman commit 0099736d7effcff676ee16c7f369c74b55221194 Author: Ard Biesheuvel Date: Fri Mar 22 18:11:32 2024 +0100 x86/efistub: Revert to heap allocated boot_params for PE entrypoint commit ae835a96d72cd025421910edb0e8faf706998727 upstream. This is a partial revert of commit 8117961d98f ("x86/efi: Disregard setup header of loaded image") which triggers boot issues on older Dell laptops. As it turns out, switching back to a heap allocation for the struct boot_params constructed by the EFI stub works around this, even though it is unclear why. Cc: Christian Heusel Reported-by: Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 436d1595fa8de5d9bc3ae5065396762367ff4818 Author: Ard Biesheuvel Date: Thu Jul 4 10:59:23 2024 +0200 x86/efistub: Avoid returning EFI_SUCCESS on error commit fb318ca0a522295edd6d796fb987e99ec41f0ee5 upstream. The fail label is only used in a situation where the previous EFI API call succeeded, and so status will be set to EFI_SUCCESS. Fix this, by dropping the goto entirely, and call efi_exit() with the correct error code. Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 891d90ab1fe59beae650b7ec654c57ae3550030c Author: Yu Zhao Date: Fri Jul 12 17:29:56 2024 -0600 mm/mglru: fix ineffective protection calculation commit 30d77b7eef019fa4422980806e8b7cdc8674493e upstream. mem_cgroup_calculate_protection() is not stateless and should only be used as part of a top-down tree traversal. shrink_one() traverses the per-node memcg LRU instead of the root_mem_cgroup tree, and therefore it should not call mem_cgroup_calculate_protection(). The existing misuse in shrink_one() can cause ineffective protection of sub-trees that are grandchildren of root_mem_cgroup. Fix it by reusing lru_gen_age_node(), which already traverses the root_mem_cgroup tree, to calculate the protection. Previously lru_gen_age_node() opportunistically skips the first pass, i.e., when scan_control->priority is DEF_PRIORITY. On the second pass, lruvec_is_sizable() uses appropriate scan_control->priority, set by set_initial_priority() from lru_gen_shrink_node(), to decide whether a memcg is too small to reclaim from. Now lru_gen_age_node() unconditionally traverses the root_mem_cgroup tree. So it should call set_initial_priority() upfront, to make sure lruvec_is_sizable() uses appropriate scan_control->priority on the first pass. Otherwise, lruvec_is_reclaimable() can return false negatives and result in premature OOM kills when min_ttl_ms is used. Link: https://lkml.kernel.org/r/20240712232956.1427127-1-yuzhao@google.com Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Yu Zhao Reported-by: T.J. Mercier Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e7767066d5d761ad4069e4131fc2b25684878fdd Author: Yu Zhao Date: Thu Jul 11 13:19:57 2024 -0600 mm/mglru: fix overshooting shrinker memory commit 3f74e6bd3b84a8b6bb3cc51609c89e5b9d58eed7 upstream. set_initial_priority() tries to jump-start global reclaim by estimating the priority based on cold/hot LRU pages. The estimation does not account for shrinker objects, and it cannot do so because their sizes can be in different units other than page. If shrinker objects are the majority, e.g., on TrueNAS SCALE 24.04.0 where ZFS ARC can use almost all system memory, set_initial_priority() can vastly underestimate how much memory ARC shrinker can evict and assign extreme low values to scan_control->priority, resulting in overshoots of shrinker objects. To reproduce the problem, using TrueNAS SCALE 24.04.0 with 32GB DRAM, a test ZFS pool and the following commands: fio --name=mglru.file --numjobs=36 --ioengine=io_uring \ --directory=/root/test-zfs-pool/ --size=1024m --buffered=1 \ --rw=randread --random_distribution=random \ --time_based --runtime=1h & for ((i = 0; i < 20; i++)) do sleep 120 fio --name=mglru.anon --numjobs=16 --ioengine=mmap \ --filename=/dev/zero --size=1024m --fadvise_hint=0 \ --rw=randrw --random_distribution=random \ --time_based --runtime=1m done To fix the problem: 1. Cap scan_control->priority at or above DEF_PRIORITY/2, to prevent the jump-start from being overly aggressive. 2. Account for the progress from mm_account_reclaimed_pages(), to prevent kswapd_shrink_node() from raising the priority unnecessarily. Link: https://lkml.kernel.org/r/20240711191957.939105-2-yuzhao@google.com Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") Signed-off-by: Yu Zhao Reported-by: Alexander Motin Cc: Wei Xu Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 9f72d8703dd6a9d324da29599e5b482b3cf23656 Author: Tetsuo Handa Date: Fri Jun 21 10:08:41 2024 +0900 mm: mmap_lock: replace get_memcg_path_buf() with on-stack buffer commit 7d6be67cfdd4a53cea7147313ca13c531e3a470f upstream. Commit 2b5067a8143e ("mm: mmap_lock: add tracepoints around lock acquisition") introduced TRACE_MMAP_LOCK_EVENT() macro using preempt_disable() in order to let get_mm_memcg_path() return a percpu buffer exclusively used by normal, softirq, irq and NMI contexts respectively. Commit 832b50725373 ("mm: mmap_lock: use local locks instead of disabling preemption") replaced preempt_disable() with local_lock(&memcg_paths.lock) based on an argument that preempt_disable() has to be avoided because get_mm_memcg_path() might sleep if PREEMPT_RT=y. But syzbot started reporting inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. and inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. messages, for local_lock() does not disable IRQ. We could replace local_lock() with local_lock_irqsave() in order to suppress these messages. But this patch instead replaces percpu buffers with on-stack buffer, for the size of each buffer returned by get_memcg_path_buf() is only 256 bytes which is tolerable for allocating from current thread's kernel stack memory. Link: https://lkml.kernel.org/r/ef22d289-eadb-4ed9-863b-fbc922b33d8d@I-love.SAKURA.ne.jp Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=40905bca570ae6784745 Fixes: 832b50725373 ("mm: mmap_lock: use local locks instead of disabling preemption") Signed-off-by: Tetsuo Handa Reviewed-by: Axel Rasmussen Cc: Nicolas Saenz Julienne Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit a39e38be632f0e1c908d70d1c9cd071c03faf895 Author: Yu Zhao Date: Thu Jul 11 13:19:56 2024 -0600 mm/mglru: fix div-by-zero in vmpressure_calc_level() commit 8b671fe1a879923ecfb72dda6caf01460dd885ef upstream. evict_folios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since folio_rotate_reclaimable() cannot handle those folios due to the isolation. The second pass tries to avoid potential double counting by deducting scan_control->nr_scanned. However, this can result in underflow of nr_scanned, under a condition where shrink_folio_list() does not increment nr_scanned, i.e., when folio_trylock() fails. The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressure_calc_level(), to become zero, resulting in the following crash: [exception RIP: vmpressure_work_fn+101] process_one_work at ffffffffa3313f2b Since scan_control->nr_scanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scan_control->nr_scanned in evict_folios(). Link: https://lkml.kernel.org/r/20240711191957.939105-1-yuzhao@google.com Fixes: 359a5e1416ca ("mm: multi-gen LRU: retry folios written back while isolated") Reported-by: Wei Xu Signed-off-by: Yu Zhao Cc: Alexander Motin Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8e157c8421daab4381da8ab88c374f94e5e0e699 Author: Miaohe Lin Date: Fri Jul 12 11:13:14 2024 +0800 mm/hugetlb: fix possible recursive locking detected warning commit 667574e873b5f77a220b2a93329689f36fb56d5d upstream. When tries to demote 1G hugetlb folios, a lockdep warning is observed: ============================================ WARNING: possible recursive locking detected 6.10.0-rc6-00452-ga4d0275fa660-dirty #79 Not tainted -------------------------------------------- bash/710 is trying to acquire lock: ffffffff8f0a7850 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0x244/0x460 but task is already holding lock: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&h->resize_lock); lock(&h->resize_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/710: #0: ffff8f118439c3f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff8f11893b9e88 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff8f1183dc4428 (kn->active#98){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffff8f0a6f48 (&h->resize_lock){+.+.}-{3:3}, at: demote_store+0xae/0x460 stack backtrace: CPU: 3 PID: 710 Comm: bash Not tainted 6.10.0-rc6-00452-ga4d0275fa660-dirty #79 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 __lock_acquire+0x10f2/0x1ca0 lock_acquire+0xbe/0x2d0 __mutex_lock+0x6d/0x400 demote_store+0x244/0x460 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa61db14887 RSP: 002b:00007ffc56c48358 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fa61db14887 RDX: 0000000000000002 RSI: 000055a030050220 RDI: 0000000000000001 RBP: 000055a030050220 R08: 00007fa61dbd1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007fa61dc1b780 R14: 00007fa61dc17600 R15: 00007fa61dc16a00 Lockdep considers this an AA deadlock because the different resize_lock mutexes reside in the same lockdep class, but this is a false positive. Place them in distinct classes to avoid these warnings. Link: https://lkml.kernel.org/r/20240712031314.2570452-1-linmiaohe@huawei.com Fixes: 8531fc6f52f5 ("hugetlb: add hugetlb demote page support") Signed-off-by: Miaohe Lin Acked-by: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit eebc67ae0b224d2b27cf8092f03333f78db7b2fc Author: Aristeu Rozanski Date: Fri Jun 21 15:00:50 2024 -0400 hugetlb: force allocating surplus hugepages on mempolicy allowed nodes commit 003af997c8a945493859dd1a2d015cc9387ff27a upstream. When trying to allocate a hugepage with no reserved ones free, it may be allowed in case a number of overcommit hugepages was configured (using /proc/sys/vm/nr_overcommit_hugepages) and that number wasn't reached. This allows for a behavior of having extra hugepages allocated dynamically, if there're resources for it. Some sysadmins even prefer not reserving any hugepages and setting a big number of overcommit hugepages. But while attempting to allocate overcommit hugepages in a multi node system (either NUMA or mempolicy/cpuset) said allocations might randomly fail even when there're resources available for the allocation. This happens due to allowed_mems_nr() only accounting for the number of free hugepages in the nodes the current process belongs to and the surplus hugepage allocation is done so it can be allocated in any node. In case one or more of the requested surplus hugepages are allocated in a different node, the whole allocation will fail due allowed_mems_nr() returning a lower value. So allocate surplus hugepages in one of the nodes the current process belongs to. Easy way to reproduce this issue is to use a 2+ NUMA nodes system: # echo 0 >/proc/sys/vm/nr_hugepages # echo 1 >/proc/sys/vm/nr_overcommit_hugepages # numactl -m0 ./tools/testing/selftests/mm/map_hugetlb 2 Repeating the execution of map_hugetlb test application will eventually fail when the hugepage ends up allocated in a different node. [aris@ruivo.org: v2] Link: https://lkml.kernel.org/r/20240701212343.GG844599@cathedrallabs.org Link: https://lkml.kernel.org/r/20240621190050.mhxwb65zn37doegp@redhat.com Signed-off-by: Aristeu Rozanski Cc: Muchun Song Cc: Aristeu Rozanski Cc: David Hildenbrand Cc: Vishal Moola Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e60f62f75c99740a28e2bf7e6044086033012a16 Author: Gavin Shan Date: Mon Jul 15 10:04:23 2024 +1000 mm/huge_memory: avoid PMD-size page cache if needed commit d659b715e94ac039803d7601505d3473393fc0be upstream. xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71 ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example. [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TEST_XFS_FILENAME; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret = 0; if (pgsize != 0x10000) { fprintf(stdout, "System with 64KB base page size is required!\n"); return -EPERM; } system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); system("echo 1 > /proc/sys/vm/drop_caches"); /* Open the xfs file */ fd = open(filename, O_RDONLY); assert(fd > 0); /* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); assert(buf != (void *)-1); fprintf(stdout, "mapped buffer at 0x%p\n", buf); /* Populate VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE); assert(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ); assert(ret == 0); /* Collapse VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); assert(ret == 0); ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE); if (ret) { fprintf(stdout, "Error %d to madvise(MADV_COLLAPSE)\n", errno); goto out; } /* Split xarray entry. Write permission is needed */ munmap(buf, TEST_MEM_SIZE); buf = (void *)-1; close(fd); fd = open(filename, O_RDWR); assert(fd > 0); fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); out: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); if (fd > 0) close(fd); return ret; } [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test ------------[ cut here ]------------ WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse \ xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net \ sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x780 sp : ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8 x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x780 truncate_inode_partial_folio+0xdc/0x160 truncate_inode_pages_range+0x1b4/0x4a8 truncate_pagecache_range+0x84/0xa0 xfs_flush_unmap_range+0x70/0x90 [xfs] xfs_file_fallocate+0xfc/0x4d8 [xfs] vfs_fallocate+0x124/0x2f0 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by correcting the supported page cache orders, different sets for DAX and other files. With it corrected, 512MB page cache becomes disallowed on all non-DAX files on ARM64 system where the base page size is 64KB. After this patch is applied, the test program fails with error -EINVAL returned from __thp_vma_allowable_orders() and the madvise() system call to collapse the page caches. Link: https://lkml.kernel.org/r/20240715000423.316491-1-gshan@redhat.com Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache") Signed-off-by: Gavin Shan Acked-by: David Hildenbrand Reviewed-by: Ryan Roberts Acked-by: Zi Yan Cc: Baolin Wang Cc: Barry Song Cc: Don Dutile Cc: Matthew Wilcox (Oracle) Cc: Peter Xu Cc: Ryan Roberts Cc: William Kucharski Cc: [5.17+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 7e1f4efb8d6140b2ec79bf760c43e1fc186e8dfc Author: Yang Shi Date: Fri Jul 12 08:58:55 2024 -0700 mm: huge_memory: use !CONFIG_64BIT to relax huge page alignment on 32 bit machines commit d9592025000b3cf26c742f3505da7b83aedc26d5 upstream. Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") didn't work for x86_32 [1]. It is because x86_32 uses CONFIG_X86_32 instead of CONFIG_32BIT. !CONFIG_64BIT should cover all 32 bit machines. [1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/ Link: https://lkml.kernel.org/r/20240712155855.1130330-1-yang@os.amperecomputing.com Fixes: 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") Signed-off-by: Yang Shi Reported-by: Yves-Alexis Perez Tested-by: Yves-Alexis Perez Acked-by: David Hildenbrand Cc: Ben Hutchings Cc: Christoph Lameter Cc: Jiri Slaby Cc: Matthew Wilcox (Oracle) Cc: Rik van Riel Cc: Salvatore Bonaccorso Cc: Suren Baghdasaryan Cc: [6.8+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b14cc2cf313bd29056fadbc8ecd7f957cf5791ff Author: Jann Horn Date: Wed Jul 24 14:49:01 2024 +0200 landlock: Don't lose track of restrictions on cred_transfer commit 39705a6c29f8a2b93cf5b99528a55366c50014d1 upstream. When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.) Cc: stable@kernel.org Fixes: 385975dca53e ("landlock: Set up the security framework and manage credentials") Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20240724-landlock-houdini-fix-v1-1-df89a4560ca3@google.com Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit f7b9c501b548b0153cc6807662a53e213cf621c3 Author: Mickaël Salaün Date: Wed Jul 24 16:54:26 2024 +0200 selftests/landlock: Add cred_transfer test commit cc374782b6ca0fd634482391da977542443d3368 upstream. Check that keyctl(KEYCTL_SESSION_TO_PARENT) preserves the parent's restrictions. Fixes: e1199815b47b ("selftests/landlock: Add user space tests") Co-developed-by: Jann Horn Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20240724.Ood5aige9she@digikod.net Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman commit 11fa625b45faf0649118b9deaf2d31c86ac41911 Author: Jason-JH.Lin Date: Thu Jul 18 22:17:04 2024 +0800 mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable() [ Upstream commit a8bd68e4329f9a0ad1b878733e0f80be6a971649 ] When mtk-cmdq unbinds, a WARN_ON message with condition pm_runtime_get_sync() < 0 occurs. According to the call tracei below: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... The root cause can be deduced to be calling pm_runtime_get_sync() after calling pm_runtime_disable() as observed below: 1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe() to bind the cmdq device to the mbox_controller, so devm_mbox_controller_unregister() will automatically unregister the device bound to the mailbox controller when the device-managed resource is removed. That means devm_mbox_controller_unregister() and cmdq_mbox_shoutdown() will be called after cmdq_remove(). 2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after devm_mbox_controller_register(), so that devm_pm_runtime_disable() will be called after cmdq_remove(), but before devm_mbox_controller_unregister(). To fix this problem, cmdq_probe() needs to move devm_mbox_controller_register() after devm_pm_runtime_enable() to make devm_pm_runtime_disable() be called after devm_mbox_controller_unregister(). Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Jason-JH.Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 131c294b775760dd81611be5aee6adecfef10d64 Author: Peng Fan Date: Fri May 24 15:56:32 2024 +0800 mailbox: imx: fix TXDB_V2 channel race condition [ Upstream commit b5ef17917f3a797a7b12d1edd51f676554e44a07 ] Two TXDB_V2 channels are used between Linux and System Manager(SM). Channel0 for normal TX, Channel 1 for notification completion. The TXDB_V2 trigger logic is using imx_mu_xcr_rmw which uses read/modify/update logic. Note: clear MUB GSR BITs, the MUA side GCR BITs will also got cleared per hardware design. Channel0 Linux read GCR->modify GCR->write GCR->M33 SM->read GSR----->clear GSR |-(1)-| Channel1 Linux start in time slot(1) read GCR->modify GCR->write GCR->M33 SM->read GSR->clear GSR So Channel1 read GCR will read back the GCR that Channel0 wrote, because M33 has not finish clear GSR, this means Channel1 GCR writing will trigger Channel1 and Channel0 interrupt both which is wrong. Channel0 will be freed(SCMI channel status set to FREE) in M33 SM when processing the 1st Channel0 interrupt. So when 2nd interrupt trigger (channel 0/1 trigger together), SM will see a freed Channel0, and report protocol error. To address the issue, not using read/modify/update logic, just use write, because write 0 to GCR will be ignored. And after write MUA GCR, wait the SM to clear MUB GSR by looping MUA GCR value. Fixes: 5bfe4067d350 ("mailbox: imx: support channel type tx doorbell v2") Reviewed-by: Ranjani Vaidyanathan Signed-off-by: Peng Fan Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit fbe0fa41d8da7eae48586298ee4d9170d0ddbd50 Author: Andrew Davis Date: Tue Jun 11 12:04:56 2024 -0500 mailbox: omap: Fix mailbox interrupt sharing [ Upstream commit 0a02bc0a34cd53c7fe5bf4bae6efb56ad47677fa ] Multiple mailbox users can share one interrupt line. This flag was mistakenly dropped as part of the FIFO removal. Mark the IRQ as shared. Reported-by: Beleswar Padhi Fixes: 3f58c1f4206f ("mailbox: omap: Remove kernel FIFO message queuing") Signed-off-by: Andrew Davis Tested-by: Beleswar Padhi Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit b6273c184d09e338c94efcf05dd3a47a296f22b1 Author: Richard Genoud Date: Fri Jun 21 17:00:55 2024 +0200 remoteproc: k3-r5: Fix IPC-only mode detection [ Upstream commit a8631f6d6344d976096b1efafdb2fbb3111bd790 ] ret variable was used to test reset status, get from reset_control_status() call. But this variable was overwritten by ti_sci_proc_get_status() a few lines bellow. And as ti_sci_proc_get_status() returns 0 or a negative value (in this latter case, followed by a return), the expression !ret was always true, Clearly, this was not what was intended: In the comment above it's said that "requires both local and module resets to be deasserted"; if reset_control_status() returns 0 it means that the reset line is deasserted. So, it's pretty clear that the return value of reset_control_status() was intended to be used instead of ti_sci_proc_get_status() return value. This could lead in an incorrect IPC-only mode detection if reset line is asserted (so reset_control_status() return > 0) and c_state != 0 and halted == 0. In this case, the old code would have detected an IPC-only mode instead of a mismatched mode. Fixes: 1168af40b1ad ("remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs") Signed-off-by: Richard Genoud Reviewed-by: Hari Nagalla Link: https://lore.kernel.org/r/20240621150058.319524-2-richard.genoud@bootlin.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 8fea24a25cd933868b8e7b3039cefa95a4a1c12e Author: Nícolas F. R. A. Prado Date: Thu Jun 27 17:20:55 2024 -0400 remoteproc: mediatek: Don't attempt to remap l1tcm memory if missing [ Upstream commit 67ca3f98070ffdf308b91e08a477fcb1e9684ae8 ] The current code doesn't check whether platform_get_resource_byname() succeeded to get the l1tcm memory, which is optional, before attempting to map it. This results in the following error message when it is missing: mtk-scp 10500000.scp: error -EINVAL: invalid resource (null) Add a check so that the remapping is only attempted if the memory region exists. This also allows to simplify the logic handling failure to remap, since a failure then is always a failure. Fixes: ca23ecfdbd44 ("remoteproc/mediatek: support L1TCM") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Tzung-Bi Shih Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240627-scp-invalid-resource-l1tcm-v1-1-7d221e6c495a@collabora.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit f3af305fd8c594f9c3953ad5009365228969754d Author: Christophe JAILLET Date: Sun Jun 23 07:50:32 2024 +0200 power: supply: ingenic: Fix some error handling paths in ingenic_battery_get_property() [ Upstream commit f8b6c1eb76f73ed721facd58d0cfb08513aad34c ] If iio_read_channel_processed() fails, 'val->intval' is not updated, but it is still *1000 just after. So, in case of error, the *1000 accumulate and 'val->intval' becomes erroneous. So instead of rescaling the value after the fact, use the dedicated scaling API. This way the result is updated only when needed. In case of error, the previous value is kept, unmodified. This should also reduce any inaccuracies resulting from the scaling. Finally, this is also slightly more efficient as it saves a function call and a multiplication. Fixes: fb24ccfbe1e0 ("power: supply: add Ingenic JZ47xx battery driver.") Signed-off-by: Christophe JAILLET Acked-by: Artur Rojek Link: https://lore.kernel.org/r/51e49c18574003db1e20c9299061a5ecd1661a3c.1719121781.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ce8bf8b992192a438bae3e130ca570dd8ddc3dae Author: Christophe JAILLET Date: Sat Jun 22 09:04:24 2024 +0200 power: supply: ab8500: Fix error handling when calling iio_read_channel_processed() [ Upstream commit 3288757087cbb93b91019ba6b7de53a1908c9d48 ] The ab8500_charger_get_[ac|vbus]_[current|voltage]() functions should return an error code on error. Up to now, an un-initialized value is returned. This makes the error handling of the callers un-reliable. Return the error code instead, to fix the issue. Fixes: 97ab78bac5d0 ("power: supply: ab8500_charger: Convert to IIO ADC") Signed-off-by: Christophe JAILLET Reviewed-by: Jonathan Cameron Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/f9f65642331c9e40aaebb888589db043db80b7eb.1719037737.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 773e7fd311ed192a943bc604f82a005c55967056 Author: Tiezhu Yang Date: Sat Jul 20 22:41:07 2024 +0800 LoongArch: Check TIF_LOAD_WATCH to enable user space watchpoint [ Upstream commit 3892b11eac5aaaeefbf717f1953288b77759d9e2 ] Currently, there are some places to set CSR.PRMD.PWE, the first one is in hw_breakpoint_thread_switch() to enable user space singlestep via checking TIF_SINGLESTEP, the second one is in hw_breakpoint_control() to enable user space watchpoint. For the latter case, it should also check TIF_LOAD_WATCH to make the logic correct and clear. Fixes: c8e57ab0995c ("LoongArch: Trigger user-space watchpoints correctly") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 420837d08cc2c9e405241ad60ced183201e82cc9 Author: Yang Yang Date: Tue Jul 16 16:26:27 2024 +0800 sbitmap: fix io hung due to race on sbitmap_word::cleared [ Upstream commit 72d04bdcf3f7d7e07d82f9757946f68802a7270a ] Configuration for sbq: depth=64, wake_batch=6, shift=6, map_nr=1 1. There are 64 requests in progress: map->word = 0xFFFFFFFFFFFFFFFF 2. After all the 64 requests complete, and no more requests come: map->word = 0xFFFFFFFFFFFFFFFF, map->cleared = 0xFFFFFFFFFFFFFFFF 3. Now two tasks try to allocate requests: T1: T2: __blk_mq_get_tag . __sbitmap_queue_get . sbitmap_get . sbitmap_find_bit . sbitmap_find_bit_in_word . __sbitmap_get_word -> nr=-1 __blk_mq_get_tag sbitmap_deferred_clear __sbitmap_queue_get /* map->cleared=0xFFFFFFFFFFFFFFFF */ sbitmap_find_bit if (!READ_ONCE(map->cleared)) sbitmap_find_bit_in_word return false; __sbitmap_get_word -> nr=-1 mask = xchg(&map->cleared, 0) sbitmap_deferred_clear atomic_long_andnot() /* map->cleared=0 */ if (!(map->cleared)) return false; /* * map->cleared is cleared by T1 * T2 fail to acquire the tag */ 4. T2 is the sole tag waiter. When T1 puts the tag, T2 cannot be woken up due to the wake_batch being set at 6. If no more requests come, T1 will wait here indefinitely. This patch achieves two purposes: 1. Check on ->cleared and update on both ->cleared and ->word need to be done atomically, and using spinlock could be the simplest solution. 2. Add extra check in sbitmap_deferred_clear(), to identify whether ->word has free bits. Fixes: ea86ea2cdced ("sbitmap: ammortize cost of clearing bits") Signed-off-by: Yang Yang Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Link: https://lore.kernel.org/r/20240716082644.659566-1-yang.yang@vivo.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 215553c3c3db1c6f3c2f1495caf1b496eded3c49 Author: Suren Baghdasaryan Date: Thu Jul 11 15:04:57 2024 -0700 alloc_tag: fix page_ext_get/page_ext_put sequence during page splitting [ Upstream commit 6ab42fe21c84d72da752923b4bd7075344f4a362 ] pgalloc_tag_sub() might call page_ext_put() using a page different from the one used in page_ext_get() call. This does not pose an issue since page_ext_put() ignores this parameter as long as it's non-NULL but technically this is wrong. Fix it by storing the original page used in page_ext_get() and passing it to page_ext_put(). Link: https://lkml.kernel.org/r/20240711220457.1751071-3-surenb@google.com Fixes: be25d1d4e822 ("mm: create new codetag references during page splitting") Signed-off-by: Suren Baghdasaryan Cc: Kees Cook Cc: Kent Overstreet Cc: Pasha Tatashin Cc: Sourav Panda Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 24b39c0ca836e8a24df4e4f9ed12236de5cdaca8 Author: Suren Baghdasaryan Date: Thu Jul 11 15:04:56 2024 -0700 lib: reuse page_ext_data() to obtain codetag_ref [ Upstream commit fd8acc0097b91fab3104fa8a66ce2fd9cf8b0c11 ] codetag_ref_from_page_ext() reimplements the same calculation as page_ext_data(). Reuse existing function instead. Link: https://lkml.kernel.org/r/20240711220457.1751071-2-surenb@google.com Fixes: dcfe378c81f7 ("lib: introduce support for page allocation tagging") Signed-off-by: Suren Baghdasaryan Cc: Kees Cook Cc: Kent Overstreet Cc: Pasha Tatashin Cc: Sourav Panda Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit fba302603cea3e8631675947f3d3a77e2bf322bc Author: Suren Baghdasaryan Date: Thu Jul 11 15:04:55 2024 -0700 lib: add missing newline character in the warning message [ Upstream commit 4810a82c8a8ae06fe6496a23fcb89a4952603e60 ] Link: https://lkml.kernel.org/r/20240711220457.1751071-1-surenb@google.com Fixes: 22d407b164ff ("lib: add allocation tagging support for memory allocation profiling") Signed-off-by: Suren Baghdasaryan Cc: Kees Cook Cc: Kent Overstreet Cc: Pasha Tatashin Cc: Sourav Panda Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 68d4c3722290ad300c295fb3435e835d200d5cb2 Author: Carlos López Date: Mon Jul 15 13:24:34 2024 +0200 s390/dasd: fix error checks in dasd_copy_pair_store() [ Upstream commit 8e64d2356cbc800b4cd0e3e614797f76bcf0cdb8 ] dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack. Fixes: a91ff09d39f9b ("s390/dasd: add copy pair setup") Signed-off-by: Carlos López Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20240715112434.2111291-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 06219163d24fbd68b2df3cd48083797d31fb4966 Author: Christophe Leroy Date: Tue Jul 2 15:51:24 2024 +0200 powerpc/8xx: fix size given to set_huge_pte_at() [ Upstream commit 7ea981070fd9ec24bc0111636038193aebb0289c ] set_huge_pte_at() expects the size of the hugepage as an int, not the psize which is the index of the page definition in table mmu_psize_defs[] Link: https://lkml.kernel.org/r/97f2090011e25d99b6b0aae73e22e1b921c5d1fb.1719928057.git.christophe.leroy@csgroup.eu Fixes: 935d4f0c6dc8 ("mm: hugetlb: add huge page size param to set_huge_pte_at()") Signed-off-by: Christophe Leroy Reviewed-by: Oscar Salvador Cc: Jason Gunthorpe Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 973850dd83b627f089a3f9c92fbfddd33404dce2 Author: Heming Zhao Date: Tue Jul 9 18:41:19 2024 +0800 md-cluster: fix hanging issue while a new disk adding [ Upstream commit fff42f213824fa434a4b6cf906b4331fe6e9302b ] The commit 1bbe254e4336 ("md-cluster: check for timeout while a new disk adding") is correct in terms of code syntax but not suite real clustered code logic. When a timeout occurs while adding a new disk, if recv_daemon() bypasses the unlock for ack_lockres:CR, another node will be waiting to grab EX lock. This will cause the cluster to hang indefinitely. How to fix: 1. In dlm_lock_sync(), change the wait behaviour from forever to a timeout, This could avoid the hanging issue when another node fails to handle cluster msg. Another result of this change is that if another node receives an unknown msg (e.g. a new msg_type), the old code will hang, whereas the new code will timeout and fail. This could help cluster_md handle new msg_type from different nodes with different kernel/module versions (e.g. The user only updates one leg's kernel and monitors the stability of the new kernel). 2. The old code for __sendmsg() always returns 0 (success) under the design (must successfully unlock ->message_lockres). This commit makes this function return an error number when an error occurs. Fixes: 1bbe254e4336 ("md-cluster: check for timeout while a new disk adding") Signed-off-by: Heming Zhao Reviewed-by: Su Yue Acked-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240709104120.22243-1-heming.zhao@suse.com Signed-off-by: Sasha Levin commit ff9400d32183b2f556e0a4d501c6089e31681257 Author: Konstantin Komarov Date: Tue Jun 18 17:11:37 2024 +0300 fs/ntfs3: Keep runs for $MFT::$ATTR_DATA and $MFT::$ATTR_BITMAP [ Upstream commit eb95678ee930d67d79fc83f0a700245ae7230455 ] We skip the run_truncate_head call also for $MFT::$ATTR_BITMAP. Otherwise wnd_map()/run_lookup_entry will not find the disk position for the bitmap parts. Fixes: 0e5b044cbf3a ("fs/ntfs3: Refactoring attr_set_size to restore after errors") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 73e38cb6836790ddb57898484c0f526b937059a9 Author: Konstantin Komarov Date: Mon Jun 17 13:43:09 2024 +0300 fs/ntfs3: Missed error return [ Upstream commit 2cbbd96820255fff4f0ad1533197370c9ccc570b ] Fixes: 3f3b442b5ad2 ("fs/ntfs3: Add bitmap") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 2e83375fd95b81be0e9ca457cc7c3f23e3575768 Author: Konstantin Komarov Date: Tue Jun 25 09:57:33 2024 +0300 fs/ntfs3: Fix the format of the "nocase" mount option [ Upstream commit d392e85fd1e8d58e460c17ca7d0d5c157848d9c1 ] The 'nocase' option was mistakenly added as fsparam_flag_no with the 'no' prefix, causing the case-insensitive mode to require the 'nonocase' option to be enabled. Fixes: a3a956c78efa ("fs/ntfs3: Add option "nocase"") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 6af0ce7182e925217210fd5a22930a9824f6ece4 Author: Csókás, Bence Date: Wed Jun 19 16:04:52 2024 +0200 rtc: interface: Add RTC offset to alarm after fix-up [ Upstream commit 463927a8902a9f22c3633960119410f57d4c8920 ] `rtc_add_offset()` is called by `__rtc_read_time()` and `__rtc_read_alarm()` to add the RTC's offset to the raw read-outs from the device drivers. However, in the latter case, a fix-up algorithm is run if the RTC device does not report a full `struct rtc_time` alarm value. In that case, the offset was forgot to be added. Fixes: fd6792bb022e ("rtc: fix alarm read and set offset") Signed-off-by: Csókás, Bence Link: https://lore.kernel.org/r/20240619140451.2800578-1-csokas.bence@prolan.hu Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 31be02ef4e54a0217e0691ff4b58d73859dea812 Author: Ryusuke Konishi Date: Wed Jul 3 03:35:12 2024 +0900 nilfs2: avoid undefined behavior in nilfs_cnt32_ge macro [ Upstream commit 0f3819e8c483771a59cf9d3190cd68a7a990083c ] According to the C standard 3.4.3p3, the result of signed integer overflow is undefined. The macro nilfs_cnt32_ge(), which compares two sequence numbers, uses signed integer subtraction that can overflow, and therefore the result of the calculation may differ from what is expected due to undefined behavior in different environments. Similar to an earlier change to the jiffies-related comparison macros in commit 5a581b367b5d ("jiffies: Avoid undefined behavior from signed overflow"), avoid this potential issue by changing the definition of the macro to perform the subtraction as unsigned integers, then cast the result to a signed integer for comparison. Link: https://lkml.kernel.org/r/20130727225828.GA11864@linux.vnet.ibm.com Link: https://lkml.kernel.org/r/20240702183512.6390-1-konishi.ryusuke@gmail.com Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 45475cbe0cc7d872978f347cde0e6e2aa727eea2 Author: SeongJae Park Date: Tue Jun 25 11:05:31 2024 -0700 selftests/damon/access_memory: use user-defined region size [ Upstream commit 34ec4344a5dabbb39e23e8daf30779892c0211a6 ] Patch series "selftests/damon: test DAMOS tried regions and {min,max}_nr_regions". This patch series fix a minor issue in a program for DAMON selftest, and implement new functionality selftests for DAMOS tried regions and {min,max}_nr_regions. The test for max_nr_regions also test the recovery from online tuning-caused limit violation, which was fixed by a previous patch [1] titled "mm/damon/core: merge regions aggressively when max_nr_regions is unmet". The first patch fixes a minor problem in the articial memory access pattern generator for tests. Following 3 patches (2-4) implement schemes tried regions test. Then a couple of patches (5-6) implementing static setup based {min,max}_nr_regions functionality test follows. Final two patches (7-8) implement dynamic max_nr_regions update test. [1] https://lore.kernel.org/20240624210650.53960C2BBFC@smtp.kernel.org This patch (of 8): 'access_memory' is an artificial memory access pattern generator for DAMON tests. It creates and accesses memory regions that the user specified the number and size via the command line. However, real access part of the program ignores the user-specified size of each region. Instead, it uses a hard-coded value, 10 MiB. Fix it to use user-defined size. Note that all existing 'access_memory' users are setting the region size as 10 MiB. Hence no real problem has happened so far. Link: https://lkml.kernel.org/r/20240625180538.73134-1-sj@kernel.org Link: https://lkml.kernel.org/r/20240625180538.73134-2-sj@kernel.org Fixes: b5906f5f7359 ("selftests/damon: add a test for update_schemes_tried_regions sysfs command") Signed-off-by: SeongJae Park Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 16a767c96902e2bbfe04144cac5cf557b3986bb6 Author: David Hildenbrand Date: Fri Jun 7 14:23:54 2024 +0200 fs/proc/task_mmu: properly detect PM_MMAP_EXCLUSIVE per page of PMD-mapped THPs [ Upstream commit 2c1f057e5be63e890f2dd89e4c25ab5eef084a91 ] We added PM_MMAP_EXCLUSIVE in 2015 via commit 77bb499bb60f ("pagemap: add mmap-exclusive bit for marking pages mapped only here"), when THPs could not be partially mapped and page_mapcount() returned something that was true for all pages of the THP. In 2016, we added support for partially mapping THPs via commit 53f9263baba6 ("mm: rework mapcount accounting to enable 4k mapping of THPs") but missed to determine PM_MMAP_EXCLUSIVE as well per page. Checking page_mapcount() on the head page does not tell the whole story. We should check each individual page. In a future without per-page mapcounts it will be different, but we'll change that to be consistent with PTE-mapped THPs once we deal with that. Link: https://lkml.kernel.org/r/20240607122357.115423-4-david@redhat.com Fixes: 53f9263baba6 ("mm: rework mapcount accounting to enable 4k mapping of THPs") Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador Cc: Kirill A. Shutemov Cc: Alexey Dobriyan Cc: Jonathan Corbet Cc: Lance Yang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 65c52a91e399846b39384c0b0e64d4209b062fac Author: David Hildenbrand Date: Fri Jun 7 14:23:53 2024 +0200 fs/proc/task_mmu: don't indicate PM_MMAP_EXCLUSIVE without PM_PRESENT [ Upstream commit da7f31ed0f4df8f61e8195e527aa83dd54896ba3 ] Relying on the mapcount for non-present PTEs that reference pages doesn't make any sense: they are not accounted in the mapcount, so page_mapcount() == 1 won't return the result we actually want to know. While we don't check the mapcount for migration entries already, we could end up checking it for swap, hwpoison, device exclusive, ... entries, which we really shouldn't. There is one exception: device private entries, which we consider fake-present (e.g., incremented the mapcount). But we won't care about that for now for PM_MMAP_EXCLUSIVE, because indicating PM_SWAP for them although they are fake-present already sounds suspiciously wrong. Let's never indicate PM_MMAP_EXCLUSIVE without PM_PRESENT. Link: https://lkml.kernel.org/r/20240607122357.115423-3-david@redhat.com Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador Cc: Alexey Dobriyan Cc: Jonathan Corbet Cc: Kirill A. Shutemov Cc: Lance Yang Signed-off-by: Andrew Morton Stable-dep-of: 2c1f057e5be6 ("fs/proc/task_mmu: properly detect PM_MMAP_EXCLUSIVE per page of PMD-mapped THPs") Signed-off-by: Sasha Levin commit 680f6ceee867d53f435900e247602b9333b6510c Author: David Hildenbrand Date: Fri Jun 7 14:23:52 2024 +0200 fs/proc/task_mmu: indicate PM_FILE for PMD-mapped file THP [ Upstream commit 3f9f022e975d930709848a86a1c79775b0585202 ] Patch series "fs/proc: move page_mapcount() to fs/proc/internal.h". With all other page_mapcount() users in the tree gone, move page_mapcount() to fs/proc/internal.h, rename it and extend the documentation to prevent future (ab)use. ... of course, I find some issues while working on that code that I sort first ;) We'll now only end up calling page_mapcount() [now folio_precise_page_mapcount()] on pages mapped via present page table entries. Except for /proc/kpagecount, that still does questionable things, but we'll leave that legacy interface as is for now. Did a quick sanity check. Likely we would want some better selfestest for /proc/$/pagemap + smaps. I'll see if I can find some time to write some more. This patch (of 6): Looks like we never taught pagemap_pmd_range() about the existence of PMD-mapped file THPs. Seems to date back to the times when we first added support for non-anon THPs in the form of shmem THP. Link: https://lkml.kernel.org/r/20240607122357.115423-1-david@redhat.com Link: https://lkml.kernel.org/r/20240607122357.115423-2-david@redhat.com Signed-off-by: David Hildenbrand Fixes: 800d8c63b2e9 ("shmem: add huge pages support") Acked-by: Kirill A. Shutemov Reviewed-by: Lance Yang Reviewed-by: Oscar Salvador Cc: David Hildenbrand Cc: Jonathan Corbet Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ce8c54d360df749265cfb8a008c1622b34b91cd6 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:55 2024 +0200 pinctrl: renesas: r8a779g0: Fix TPU suffixes [ Upstream commit 3d144ef10a448f89065dcff39c40d90ac18e035e ] The Timer Pulse Unit channels have two alternate pin groups: "tpu_to[0-3]" and "tpu_to[0-3]_a". Increase uniformity by adopting R-Car V4M naming: - Rename "tpu_to[0-3]_a" to "tpu_to[0-3]_b", - Rename "tpu_to[0-3]" to "tpu_to[0-3]_a", Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions") Fixes: 85a9cbe4c57bb958 ("pinctrl: renesas: r8a779g0: Add missing TPU0TOx_A") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/0dd9428bc24e97e1001ed3976b1cb98966f5e7e3.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit d6452ef3a6e31d63dc3d7e616b2914cf6837383c Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:54 2024 +0200 pinctrl: renesas: r8a779g0: Fix TCLK suffixes [ Upstream commit bfd2428f3a80647af681df4793e473258aa755da ] The Pin Multiplex attachment in Rev.1.10 of the R-Car V4H Series Hardware User's Manual still has two alternate pins named both TCLK3 and TCLK4. To differentiate, the pin control driver uses "TCLK[34]" and "TCLK[34]_X". In addition, there are alternate pins without suffix, and with an "_A" or "_B" suffix. Increase uniformity by adopting R-Car V4M naming: - Rename "TCLK2_B" to "TCLK2_C", - Rename "TCLK[12]_A" to "TCLK[12]_B", - Rename "TCLK[12]" to "TCLK[12]_A", - Rename "TCLK[34]_A" to "TCLK[34]_C", - Rename "TCLK[34]_X" to "TCLK[34]_A", - Rename "TCLK[34]" to "TCLK[34]_B". Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 0df46188a58895e1 ("pinctrl: renesas: r8a779g0: Add missing TCLKx_A/TCLKx_B/TCLKx_X") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/2845ff1f8fe1fd8d23d2f307ad5e8eb8243da608.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 488f0a526df051fe24efbbce1b4548f71a1aeb9f Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:53 2024 +0200 pinctrl: renesas: r8a779g0: FIX PWM suffixes [ Upstream commit 0aabdc9a4d3644fd57d804b283b2ab0f9c28dc6c ] PWM channels 0, 2, 8, and 9 do not have alternate pins. Remove their "_a" or "_b" suffixes to increase uniformity. Fixes: c606c2fde2330547 ("pinctrl: renesas: r8a779g0: Add missing PWM") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/abb748e6e1e4e7d78beac7d96e7a0a3481b32e75.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 91bbe8e3040925fc88a6316963e34c533aef9cf5 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:52 2024 +0200 pinctrl: renesas: r8a779g0: Fix IRQ suffixes [ Upstream commit c391dcde3884dbbea37f57dd2625225d8661da97 ] The suffixes of the IRQ identifiers for external interrupts 0-3 are inconsistent: - "IRQ0" and "IRQ0_A", - "IRQ1" and "IRQ1_A", - "IRQ2" and "IRQ2_A", - "IRQ3" and "IRQ3_B". The suffixes for external interrupts 4 and 5 do follow conventional naming: - "IRQ4A" and IRQ4_B", - "IRQ5". Fix this by adopting R-Car V4M naming: - Rename "IRQ[0-2]_A" to "IRQ[0-2]_B", - Rename "IRQ[0-3]" to "IRQ[0-3]_A". Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 1b23d8a478bea9d1 ("pinctrl: renesas: r8a779g0: Add missing IRQx_A/IRQx_B") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/8ce9baf0a0f9346544a3ac801fd962c7c12fd247.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 42c06e713fcad0867cc0e46f5b91aab8e74e54e2 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:51 2024 +0200 pinctrl: renesas: r8a779g0: Fix (H)SCIF3 suffixes [ Upstream commit 5350f38150a171322b50c0a48efa671885f87050 ] (H)SCIF instance 3 has two alternate pin groups: "hscif3" and "hscif3_a", resp. "scif3" and "scif3_a", but the actual meanings of the pins within the groups do not match. Increase uniformity by adopting R-Car V4M naming: - Rename "hscif3_a" to "hscif3_b", - Rename "hscif3" to "hscif3_a", - Rename "scif3" to "scif3_b". While at it, remove unneeded separators. Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions") Fixes: 213b713255defaa6 ("pinctrl: renesas: r8a779g0: Add missing HSCIF3_A") Fixes: 49e4697656bdd1cd ("pinctrl: renesas: r8a779g0: Add missing SCIF3") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/61fdde58e369e8070ffd3c5811c089e6219c7ecc.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit f634a01daf92a891eba1aaf921df0679936d8f10 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:50 2024 +0200 pinctrl: renesas: r8a779g0: Fix (H)SCIF1 suffixes [ Upstream commit 3cf834a1669ea433aeee4c82c642776899c87451 ] The Pin Multiplex attachment in Rev.1.10 of the R-Car V4H Series Hardware User's Manual still has two alternate pin groups (GP0_14-18 and GP1_6-10) each named both HSCIF1 and SCIF1. To differentiate, the pin control driver uses "(h)scif1" and "(h)scif1_x", which were considered temporary names until the conflict was sorted out. Fix this by adopting R-Car V4M naming: - Rename "(h)scif1" to "(h)scif1_a", - Rename "(h)scif1_x" to "(h)scif1_b". Adopt the R-Car V4M naming "(h)scif1_a" and "(h)scif1_b" to increase uniformity. While at it, remove unneeded separators. Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions") Fixes: cf4f7891847bc558 ("pinctrl: renesas: r8a779g0: Add missing HSCIF1_X") Fixes: 9c151c2be92becf2 ("pinctrl: renesas: r8a779g0: Add missing SCIF1_X") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/5009130d1867e12abf9b231c8838fd05e2b28bee.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit f20026c2377460b08ebec858058cf1b7105a5325 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:49 2024 +0200 pinctrl: renesas: r8a779g0: Fix FXR_TXEN[AB] suffixes [ Upstream commit 4976d61ca39ce51f422e094de53b46e2e3ac5c0d ] The Pin Multiplex attachment in Rev.1.10 of the R-Car V4H Series Hardware User's Manual still has two alternate pins named both "FXR_TXEN[AB]". To differentiate, the pin control driver uses "FXR_TXEN[AB]" and "FXR_TXEN[AB]_X", which were considered temporary names until the conflict was sorted out. Fix this by adopting R-Car V4M naming: - Rename "FXR_TXEN[AB]" to "FXR_TXEN[AB]_A", - Rename "FXR_TXEN[AB]_X" to "FXR_TXEN[AB]_B". Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 1c2646b5cebfff07 ("pinctrl: renesas: r8a779g0: Add missing FlexRay") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/5e1e9abb46c311d4c54450d991072d6d0e66f14c.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6474ac2f334b41a9c60583df9bb3e2cfcd955394 Author: Geert Uytterhoeven Date: Fri Jun 7 12:13:48 2024 +0200 pinctrl: renesas: r8a779g0: Fix CANFD5 suffix [ Upstream commit 77fa9007ac31e80674beadc452d3f3614f283e18 ] CAN-FD instance 5 has two alternate pin groups: "canfd5" and "canfd5_b". Rename the former to "canfd5_a" to increase uniformity. While at it, remove the unneeded separator. Fixes: ad9bb2fec66262b0 ("pinctrl: renesas: Initial R8A779G0 (R-Car V4H) PFC support") Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and functions") Fixes: c2b4b2cd632d17e7 ("pinctrl: renesas: r8a779g0: Add missing CANFD5_B") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/10b22d54086ed11cdfeb0004583029ccf249bdb9.1717754960.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 500295cdc5247ba0078ebe7cec71df0d30e51cc6 Author: Richard Genoud Date: Tue Jun 18 16:18:49 2024 +0200 rtc: tps6594: Fix memleak in probe [ Upstream commit 94d4154792abf30ee6081d35beaeef035816e294 ] struct rtc_device is allocated twice in probe(), once with devm_kzalloc(), and then with devm_rtc_allocate_device(). The allocation with devm_kzalloc() is lost and superfluous. Fixes: 9f67c1e63976 ("rtc: tps6594: Add driver for TPS6594 RTC") Signed-off-by: Richard Genoud Link: https://lore.kernel.org/r/20240618141851.1810000-2-richard.genoud@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit c41eadba18049d1b9ade7767c675d10a9641e44c Author: Konstantin Komarov Date: Mon Jun 17 15:13:09 2024 +0300 fs/ntfs3: Fix field-spanning write in INDEX_HDR [ Upstream commit 2f3e176fee66ac86ae387787bf06457b101d9f7a ] Fields flags and res[3] replaced with one 4 byte flags. Fixes: 4534a70b7056 ("fs/ntfs3: Add headers and misc files") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d7d3cbb23136a78581bee58e71d92306afab8e61 Author: Andy Shevchenko Date: Wed Apr 24 00:01:01 2024 +0300 fs/ntfs3: Drop stray '\' (backslash) in formatting string [ Upstream commit b366809dd151e8abb29decda02fd6a78b498831f ] CHECK /home/andy/prj/linux-topic-uart/fs/ntfs3/super.c fs/ntfs3/super.c:471:23: warning: unknown escape sequence: '\%' Drop stray '\' (backslash) in formatting string. Fixes: d27e202b9ac4 ("fs/ntfs3: Add more info into /proc/fs/ntfs3//volinfo") Signed-off-by: Andy Shevchenko Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 8e0f398c6f5c39907d772c7b2db9863bbe3607f9 Author: Konstantin Komarov Date: Thu May 30 10:59:13 2024 +0300 fs/ntfs3: Correct undo if ntfs_create_inode failed [ Upstream commit f28d0866d8ff798aa497971f93d0cc58f442d946 ] Clusters allocated for Extended Attributes, must be freed when rolling back inode creation. Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit d5ad80aabd5a76a5de52b7663b1f3223dd01ea38 Author: Konstantin Komarov Date: Thu May 30 10:54:07 2024 +0300 fs/ntfs3: Replace inode_trylock with inode_lock [ Upstream commit 69505fe98f198ee813898cbcaf6770949636430b ] The issue was detected due to xfstest 465 failing. Fixes: 4342306f0f0d ("fs/ntfs3: Add file operations and implementation") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 33d8dfc0bdaf94d917b3afd3f7bfb7dd2ec041b1 Author: Peng Fan Date: Sat May 4 21:20:16 2024 +0800 pinctrl: freescale: mxs: Fix refcount of child [ Upstream commit 7f500f2011c0bbb6e1cacab74b4c99222e60248e ] of_get_next_child() will increase refcount of the returned node, need use of_node_put() on it when done. Per current implementation, 'child' will be override by for_each_child_of_node(np, child), so use of_get_child_count to avoid refcount leakage. Fixes: 17723111e64f ("pinctrl: add pinctrl-mxs support") Signed-off-by: Peng Fan Link: https://lore.kernel.org/20240504-pinctrl-cleanup-v2-18-26c5f2dc1181@nxp.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b3c0850f871c4ffe80ac9a28a410f294bc407b61 Author: Yang Yingliang Date: Thu Jun 6 10:37:04 2024 +0800 pinctrl: ti: ti-iodelay: fix possible memory leak when pinctrl_enable() fails [ Upstream commit 9b401f4a7170125365160c9af267a41ff6b39001 ] This driver calls pinctrl_register_and_init() which is not devm_ managed, it will leads memory leak if pinctrl_enable() fails. Replace it with devm_pinctrl_register_and_init(). And add missing of_node_put() in the error path. Fixes: 5038a66dad01 ("pinctrl: core: delete incorrect free in pinctrl_enable()") Signed-off-by: Yang Yingliang Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240606023704.3931561-4-yangyingliang@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d90085d566a9bb93a355cbd6c16168e3244fcdfb Author: Yang Yingliang Date: Thu Jun 6 10:37:03 2024 +0800 pinctrl: single: fix possible memory leak when pinctrl_enable() fails [ Upstream commit 8f773bfbdd428819328a2d185976cfc6ae811cd3 ] This driver calls pinctrl_register_and_init() which is not devm_ managed, it will leads memory leak if pinctrl_enable() fails. Replace it with devm_pinctrl_register_and_init(). And call pcs_free_resources() if pinctrl_enable() fails. Fixes: 5038a66dad01 ("pinctrl: core: delete incorrect free in pinctrl_enable()") Signed-off-by: Yang Yingliang Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240606023704.3931561-3-yangyingliang@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 272b9b8e9b7af11a150b2c5cef659900ca6549cd Author: Yang Yingliang Date: Thu Jun 6 10:37:02 2024 +0800 pinctrl: core: fix possible memory leak when pinctrl_enable() fails [ Upstream commit ae1cf4759972c5fe665ee4c5e0c29de66fe3cf4a ] In devm_pinctrl_register(), if pinctrl_enable() fails in pinctrl_register(), the "pctldev" has not been added to dev resources, so devm_pinctrl_dev_release() can not be called, it leads memory leak. Introduce pinctrl_uninit_controller(), call it in the error path to free memory. Fixes: 5038a66dad01 ("pinctrl: core: delete incorrect free in pinctrl_enable()") Signed-off-by: Yang Yingliang Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240606023704.3931561-2-yangyingliang@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 065d1ee1a0c8dcd47be0bd2c9cf38000ac15861d Author: Dmitry Yashin Date: Wed May 15 17:16:32 2024 +0500 pinctrl: rockchip: update rk3308 iomux routes [ Upstream commit a8f2548548584549ea29d43431781d67c4afa42b ] Some of the rk3308 iomux routes in rk3308_mux_route_data belong to the rk3308b SoC. Remove them and correct i2c3 routes. Fixes: 7825aeb7b208 ("pinctrl: rockchip: add rk3308 SoC support") Signed-off-by: Dmitry Yashin Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20240515121634.23945-2-dmt.yashin@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit edfef987bc5c88684d7335f06de4909c18e9a889 Author: Konstantin Komarov Date: Mon Jun 3 09:58:13 2024 +0300 fs/ntfs3: Add missing .dirty_folio in address_space_operations [ Upstream commit 0f9579d9e0331b6255132ac06bdf2c0a01cceb90 ] After switching from pages to folio [1], it became evident that the initialization of .dirty_folio for page cache operations was missed for compressed files. [1] https://lore.kernel.org/ntfs3/20240422193203.3534108-1-willy@infradead.org Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 0bbd61e1ac77f079dad583a249aa854aa4dfd073 Author: Konstantin Komarov Date: Tue Jun 4 10:41:39 2024 +0300 fs/ntfs3: Fix getting file type [ Upstream commit 24c5100aceedcd47af89aaa404d4c96cd2837523 ] An additional condition causes the mft record to be read from disk and get the file type dt_type. Fixes: 22457c047ed97 ("fs/ntfs3: Modified fix directory element type detection") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 2f7236ba9f7c5c6b68229ddbc4094fdd01e51cc5 Author: Konstantin Komarov Date: Mon Jun 3 20:36:03 2024 +0300 fs/ntfs3: Missed NI_FLAG_UPDATE_PARENT setting [ Upstream commit 1c308ace1fd6de93bd0b7e1a5e8963ab27e2c016 ] Fixes: be71b5cba2e64 ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 539bd10ab6539e6597835761c7a1a657efd3add3 Author: Konstantin Komarov Date: Mon Jun 3 20:07:44 2024 +0300 fs/ntfs3: Deny getting attr data block in compressed frame [ Upstream commit 69943484b95267c94331cba41e9e64ba7b24f136 ] Attempting to retrieve an attribute data block in a compressed frame is ignored. Fixes: be71b5cba2e64 ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit ff73b9187376dc24baac9264f09f988c7be8d1cd Author: Konstantin Komarov Date: Thu May 16 01:10:01 2024 +0300 fs/ntfs3: Fix transform resident to nonresident for compressed files [ Upstream commit 25610ff98d4a34e6a85cbe4fd8671be6b0829f8f ] Сorrected calculation of required space len (in clusters) for attribute data storage in case of compression. Fixes: be71b5cba2e64 ("fs/ntfs3: Add attrib operations") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit a62241fb49ac12e118521645717268452ac41f3a Author: Konstantin Komarov Date: Thu May 16 00:41:02 2024 +0300 fs/ntfs3: Merge synonym COMPRESSION_UNIT and NTFS_LZNT_CUNIT [ Upstream commit 487f8d482a7e51a640b8f955a398f906a4f83951 ] COMPRESSION_UNIT and NTFS_LZNT_CUNIT mean the same thing (1u< Stable-dep-of: 25610ff98d4a ("fs/ntfs3: Fix transform resident to nonresident for compressed files") Signed-off-by: Sasha Levin commit 1fd2bf31aa542b269bbbedbb380b3271dde2e3d0 Author: Martin Willi Date: Wed Jul 17 11:08:20 2024 +0200 net: dsa: b53: Limit chip-wide jumbo frame config to CPU ports [ Upstream commit c5118072e228e7e4385fc5ac46b2e31cf6c4f2d3 ] Broadcom switches supported by the b53 driver use a chip-wide jumbo frame configuration. In the commit referenced with the Fixes tag, the setting is applied just for the last port changing its MTU. While configuring CPU ports accounts for tagger overhead, user ports do not. When setting the MTU for a user port, the chip-wide setting is reduced to not include the tagger overhead, resulting in an potentially insufficient chip-wide maximum frame size for the CPU port. As, by design, the CPU port MTU is adjusted for any user port change, apply the chip-wide setting only for CPU ports. This aligns the driver to the behavior of other switch drivers. Fixes: 6ae5834b983a ("net: dsa: b53: add MTU configuration support") Suggested-by: Vladimir Oltean Signed-off-by: Martin Willi Reviewed-by: Vladimir Oltean Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ea59437fe8aa4697eaba51ecfce0ac00e37f8d2d Author: Martin Willi Date: Wed Jul 17 11:08:19 2024 +0200 net: dsa: mv88e6xxx: Limit chip-wide frame size config to CPU ports [ Upstream commit 66b6095c264e1b4e0a441c6329861806504e06c6 ] Marvell chips not supporting per-port jumbo frame size configurations use a chip-wide frame size configuration. In the commit referenced with the Fixes tag, the setting is applied just for the last port changing its MTU. While configuring CPU ports accounts for tagger overhead, user ports do not. When setting the MTU for a user port, the chip-wide setting is reduced to not include the tagger overhead, resulting in an potentially insufficient maximum frame size for the CPU port. Specifically, sending full-size frames from the CPU port on a MV88E6097 having a user port MTU of 1500 bytes results in dropped frames. As, by design, the CPU port MTU is adjusted for any user port change, apply the chip-wide setting only for CPU ports. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Suggested-by: Vladimir Oltean Signed-off-by: Martin Willi Reviewed-by: Vladimir Oltean Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bc410a24a99c222fb85d0d67b7585cf6423417b8 Author: Ido Schimmel Date: Mon Jul 15 17:23:54 2024 +0300 ipv4: Fix incorrect TOS in fibmatch route get reply [ Upstream commit f036e68212c11e5a7edbb59b5e25299341829485 ] The TOS value that is returned to user space in the route get reply is the one with which the lookup was performed ('fl4->flowi4_tos'). This is fine when the matched route is configured with a TOS as it would not match if its TOS value did not match the one with which the lookup was performed. However, matching on TOS is only performed when the route's TOS is not zero. It is therefore possible to have the kernel incorrectly return a non-zero TOS: # ip link add name dummy1 up type dummy # ip address add 192.0.2.1/24 dev dummy1 # ip route get fibmatch 192.0.2.2 tos 0xfc 192.0.2.0/24 tos 0x1c dev dummy1 proto kernel scope link src 192.0.2.1 Fix by instead returning the DSCP field from the FIB result structure which was populated during the route lookup. Output after the patch: # ip link add name dummy1 up type dummy # ip address add 192.0.2.1/24 dev dummy1 # ip route get fibmatch 192.0.2.2 tos 0xfc 192.0.2.0/24 dev dummy1 proto kernel scope link src 192.0.2.1 Extend the existing selftests to not only verify that the correct route is returned, but that it is also returned with correct "tos" value (or without it). Fixes: b61798130f1b ("net: ipv4: RTM_GETROUTE: return matched fib result when requested") Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Reviewed-by: Guillaume Nault Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3ff2e0a82532b9dda4740830ceebdf13160cd727 Author: Ido Schimmel Date: Mon Jul 15 17:23:53 2024 +0300 ipv4: Fix incorrect TOS in route get reply [ Upstream commit 338bb57e4c2a1c2c6fc92f9c0bd35be7587adca7 ] The TOS value that is returned to user space in the route get reply is the one with which the lookup was performed ('fl4->flowi4_tos'). This is fine when the matched route is configured with a TOS as it would not match if its TOS value did not match the one with which the lookup was performed. However, matching on TOS is only performed when the route's TOS is not zero. It is therefore possible to have the kernel incorrectly return a non-zero TOS: # ip link add name dummy1 up type dummy # ip address add 192.0.2.1/24 dev dummy1 # ip route get 192.0.2.2 tos 0xfc 192.0.2.2 tos 0x1c dev dummy1 src 192.0.2.1 uid 0 cache Fix by adding a DSCP field to the FIB result structure (inside an existing 4 bytes hole), populating it in the route lookup and using it when filling the route get reply. Output after the patch: # ip link add name dummy1 up type dummy # ip address add 192.0.2.1/24 dev dummy1 # ip route get 192.0.2.2 tos 0xfc 192.0.2.2 dev dummy1 src 192.0.2.1 uid 0 cache Fixes: 1a00fee4ffb2 ("ipv4: Remove rt_key_{src,dst,tos} from struct rtable.") Signed-off-by: Ido Schimmel Reviewed-by: David Ahern Reviewed-by: Guillaume Nault Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c5d21aabf1b31a79f228508af33aee83456bc1b0 Author: Pablo Neira Ayuso Date: Mon Jul 15 16:14:42 2024 +0200 net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE [ Upstream commit 120f1c857a73e52132e473dee89b340440cb692b ] The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net") but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat given __skb_get_hash() is used by the nftables tracing infrastructure to to identify packets in traces. [69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] [69133.562049] ? __warn+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230 [ 1211.841776] ? mod_find+0xbf/0xe0 [ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0 [ 1211.841798] ? bpf_ksym_find+0x56/0xe0 [ 1211.841807] ? __rcu_read_unlock+0x2a/0x70 [ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables] [ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables] [ 1211.841964] ? get_stack_info+0x2b/0x80 [ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables] [ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables] Fixes: 9b52e3f267a6 ("flow_dissector: handle no-skb use case") Suggested-by: Willem de Bruijn Signed-off-by: Pablo Neira Ayuso Reviewed-by: Willem de Bruijn Link: https://patch.msgid.link/20240715141442.43775-1-pablo@netfilter.org Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c62bf09262c5e97ee29f51f64c89728f63cf86fd Author: Joshua Washington Date: Tue Jul 16 10:10:41 2024 -0700 gve: Fix XDP TX completion handling when counters overflow [ Upstream commit 03b54bad26f3c78bb1f90410ec3e4e7fe197adc9 ] In gve_clean_xdp_done, the driver processes the TX completions based on a 32-bit NIC counter and a 32-bit completion counter stored in the tx queue. Fix the for loop so that the counter wraparound is handled correctly. Fixes: 75eaae158b1b ("gve: Add XDP DROP and TX support for GQI-QPL format") Signed-off-by: Joshua Washington Signed-off-by: Praveen Kaligineedi Reviewed-by: Simon Horman Link: https://patch.msgid.link/20240716171041.1561142-1-pkaligineedi@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c420cd5d5bc6797f3a8824e7d74f38f0c286fca5 Author: Chen Hanxiao Date: Thu Jun 27 14:15:15 2024 +0800 ipvs: properly dereference pe in ip_vs_add_service [ Upstream commit cbd070a4ae62f119058973f6d2c984e325bce6e7 ] Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression Fixes: 39b972231536 ("ipvs: handle connections started by real-servers") Signed-off-by: Chen Hanxiao Acked-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8058c88ac0df21239daee54b5934d5c80ca9685f Author: Florian Westphal Date: Mon Jul 15 13:54:03 2024 +0200 netfilter: nf_set_pipapo: fix initial map fill [ Upstream commit 791a615b7ad2258c560f91852be54b0480837c93 ] The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where first field size is not the largest. Followup patch adds a test case to nft_concat_range.sh selftest script. Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough. Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reported-by: Yi Chen Cc: Stefano Brivio Signed-off-by: Florian Westphal Reviewed-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 74de442b8e12a207c07953ee068009a7701aff8f Author: Pablo Neira Ayuso Date: Sat Jul 13 16:47:38 2024 +0200 netfilter: ctnetlink: use helper function to calculate expect ID [ Upstream commit 782161895eb4ac45cf7cfa8db375bd4766cb8299 ] Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace. Fixes: 3c79107631db ("netfilter: ctnetlink: don't use conntrack/expect object addresses as id") Reported-by: zdi-disclosures@trendmicro.com Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 487ded1dbb0c4b371596a70937a32e4c64a1fb54 Author: Jiaxun Yang Date: Sun Jul 14 10:52:57 2024 +0800 MIPS: Fix fallback march for SB1 [ Upstream commit 2326c8f2022636a1e47402ffd09a3b28f737275f ] Fallback march for SB1 should be mips64 instead of mips64r1. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202407111851.LwDasTcp-lkp@intel.com/ Fixes: bfc0a330c1b4 ("MIPS: Fallback CPU -march flag to ISA level if unsupported") Signed-off-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit d2aea330f4de1cebe75741a301be597714aa408a Author: Konstantin Taranov Date: Thu Jul 11 06:37:57 2024 -0700 RDMA/mana_ib: Set correct device into ib [ Upstream commit 1df03a4b44146c4f720d793915747272c7773a3e ] Add mana_get_primary_netdev_rcu helper to get a primary netdevice for a given port. When mana is used with netvsc, the VF netdev is controlled by an upper netvsc device. In a baremetal case, the VF netdev is the primary device. Use the mana_get_primary_netdev_rcu() helper in the mana_ib to get the correct device for querying network states. Fixes: 8b184e4f1c32 ("RDMA/mana_ib: Enable RoCE on port 1") Signed-off-by: Konstantin Taranov Link: https://lore.kernel.org/r/1720705077-322-1-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 03ab92bb185c626183b7936928346f7139fdf3b8 Author: Konstantin Taranov Date: Thu May 30 04:55:16 2024 -0700 RDMA/mana_ib: set node_guid [ Upstream commit 65357e2c164a08bf20849dd55f46aa71e00334fa ] Use the mac address for the node_guid of the IB device. Signed-off-by: Konstantin Taranov Link: https://lore.kernel.org/r/1717070117-1234-2-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Stable-dep-of: 1df03a4b4414 ("RDMA/mana_ib: Set correct device into ib") Signed-off-by: Sasha Levin commit 79dc0c2200cf4fe2f1e8a95a4a16a1b2c8549972 Author: Jack Wang Date: Wed Jul 10 14:21:02 2024 +0200 bnxt_re: Fix imm_data endianness [ Upstream commit 95b087f87b780daafad1dbb2c84e81b729d5d33f ] When map a device between servers with MLX and BCM RoCE nics, RTRS server complain about unknown imm type, and can't map the device, After more debug, it seems bnxt_re wrongly handle the imm_data, this patch fixed the compat issue with MLX for us. In off list discussion, Selvin confirmed HW is working in little endian format and all data needs to be converted to LE while providing. This patch fix the endianness for imm_data Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Signed-off-by: Jack Wang Link: https://lore.kernel.org/r/20240710122102.37569-1-jinpu.wang@ionos.com Acked-by: Selvin Xavier Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit abd9c8843cbc1d730ebae1076fbea6e14b0f5867 Author: David Ahern Date: Wed Jul 10 13:33:10 2024 -0700 RDMA: Fix netdev tracker in ib_device_set_netdev [ Upstream commit 2043a14fb3de9d88440b21590f714306fcbbd55f ] If a netdev has already been assigned, ib_device_set_netdev needs to release the reference on the older netdev but it is mistakenly being called for the new netdev. Fix it and in the process use netdev_put to be symmetrical with the netdev_hold. Fixes: 09f530f0c6d6 ("RDMA: Add netdevice_tracker to ib_device_set_netdev()") Signed-off-by: David Ahern Link: https://lore.kernel.org/r/20240710203310.19317-1-dsahern@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e1640fed0377bf7276efb70d03cb821a6931063d Author: David Gstir Date: Wed Jul 3 14:49:58 2024 +0200 crypto: mxs-dcp - Ensure payload is zero when using key slot [ Upstream commit dd52b5eeb0f70893f762da7254e923fd23fd1379 ] We could leak stack memory through the payload field when running AES with a key from one of the hardware's key slots. Fix this by ensuring the payload field is set to 0 in such cases. This does not affect the common use case when the key is supplied from main memory via the descriptor payload. Signed-off-by: David Gstir Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202405270146.Y9tPoil8-lkp@intel.com/ Fixes: 3d16af0b4cfa ("crypto: mxs-dcp: Add support for hardware-bound keys") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 133a2823a9ba23f618437257d4c1bbbabcd161f1 Author: Jon Pan-Doh Date: Tue Jul 9 16:49:13 2024 -0700 iommu/vt-d: Fix identity map bounds in si_domain_init() [ Upstream commit 31000732d56b43765d51e08cccb68818fbc0032c ] Intel IOMMU operates on inclusive bounds (both generally aas well as iommu_domain_identity_map()). Meanwhile, for_each_mem_pfn_range() uses exclusive bounds for end_pfn. This creates an off-by-one error when switching between the two. Fixes: c5395d5c4a82 ("intel-iommu: Clean up iommu_domain_identity_map()") Signed-off-by: Jon Pan-Doh Tested-by: Sudheer Dantuluri Suggested-by: Gary Zibrat Reviewed-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240709234913.2749386-1-pandoh@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 97204e45721f32284cd9914667e8b8a1166e6369 Author: Chengchang Tang Date: Wed Jul 10 21:37:05 2024 +0800 RDMA/hns: Fix mbx timing out before CMD execution is completed [ Upstream commit bbddfa2255dd0800209697fd12378e02ed05f833 ] When a large number of tasks are issued, the speed of HW processing mbx will slow down. The standard for judging mbx timeout in the current firmware is 30ms, and the current timeout standard for the driver is also 30ms. Considering that firmware scheduling in multi-function scenarios takes a certain amount of time, this will cause the driver to time out too early and report a failure before mbx execution times out. This patch introduces a new mechanism that can set different timeouts for different cmds and extends the timeout of mbx to 35ms. Fixes: a04ff739f2a9 ("RDMA/hns: Add command queue support for hip08 RoCE driver") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-9-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 16c003fa616d257180bfa67ba76691216286cb9c Author: Chengchang Tang Date: Wed Jul 10 21:37:04 2024 +0800 RDMA/hns: Fix insufficient extend DB for VFs. [ Upstream commit 0b8e658f70ffd5dc7cda3872fd524d657d4796b7 ] VFs and its PF will share the memory of the extend DB. Currently, the number of extend DB allocated by driver is only enough for PF. This leads to a probability of DB loss and some other problems in scenarios where both PF and VFs use a large number of QPs. Fixes: 6b63597d3540 ("RDMA/hns: Add TSQ link table support") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-8-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d0aa92bd8111bc929c89be6961d8a6cc1245d20f Author: Chengchang Tang Date: Wed Jul 10 21:37:03 2024 +0800 RDMA/hns: Fix undifined behavior caused by invalid max_sge [ Upstream commit 36397b907355e2fdb5a25a02a7921a937fd8ef4c ] If max_sge has been set to 0, roundup_pow_of_two() in set_srq_basic_param() may have undefined behavior. Fixes: 9dd052474a26 ("RDMA/hns: Allocate one more recv SGE for HIP08") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-7-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f169b6243032efe9287b816a6cacf0855674581c Author: Chengchang Tang Date: Wed Jul 10 21:37:02 2024 +0800 RDMA/hns: Fix shift-out-bounds when max_inline_data is 0 [ Upstream commit 24c6291346d98c7ece4f4bfeb5733bec1d6c7b4f ] A shift-out-bounds may occur, if the max_inline_data has not been set. The related log: UBSAN: shift-out-of-bounds in kernel/include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' Call trace: dump_backtrace+0xb0/0x118 show_stack+0x20/0x38 dump_stack_lvl+0xbc/0x120 dump_stack+0x1c/0x28 __ubsan_handle_shift_out_of_bounds+0x104/0x240 set_ext_sge_param+0x40c/0x420 [hns_roce_hw_v2] hns_roce_create_qp+0xf48/0x1c40 [hns_roce_hw_v2] create_qp.part.0+0x294/0x3c0 ib_create_qp_kernel+0x7c/0x150 create_mad_qp+0x11c/0x1e0 ib_mad_init_device+0x834/0xc88 add_client_context+0x248/0x318 enable_device_and_get+0x158/0x280 ib_register_device+0x4ac/0x610 hns_roce_init+0x890/0xf98 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x398/0x720 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x108/0x1e0 [hns_roce_hw_v2] hclge_init_roce_client_instance+0x1a0/0x358 [hclge] hclge_init_client_instance+0xa0/0x508 [hclge] hnae3_register_client+0x18c/0x210 [hnae3] hns_roce_hw_v2_init+0x28/0xff8 [hns_roce_hw_v2] do_one_initcall+0xe0/0x510 do_init_module+0x110/0x370 load_module+0x2c6c/0x2f20 init_module_from_file+0xe0/0x140 idempotent_init_module+0x24c/0x350 __arm64_sys_finit_module+0x88/0xf8 invoke_syscall+0x68/0x1a0 el0_svc_common.constprop.0+0x11c/0x150 do_el0_svc+0x38/0x50 el0_svc+0x50/0xa0 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x1a4/0x1a8 Fixes: 0c5e259b06a8 ("RDMA/hns: Fix incorrect sge nums calculation") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ecdf900a5a3372bc0208e0701a116f112eb6039c Author: Chengchang Tang Date: Wed Jul 10 21:37:01 2024 +0800 RDMA/hns: Fix missing pagesize and alignment check in FRMR [ Upstream commit d387d4b54eb84208bd4ca13572e106851d0a0819 ] The offset requires 128B alignment and the page size ranges from 4K to 128M. Fixes: 68a997c5d28c ("RDMA/hns: Add FRMR support for hip08") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6dbec7322f620c0763c7429685317026057df39c Author: Junxian Huang Date: Wed Jul 10 21:37:00 2024 +0800 RDMA/hns: Fix unmatch exception handling when init eq table fails [ Upstream commit 543fb987bd63ed27409b5dea3d3eec27b9c1eac9 ] The hw ctx should be destroyed when init eq table fails. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 06580b33c183c9f98e2a2ca96a86137179032c08 Author: Junxian Huang Date: Wed Jul 10 21:36:59 2024 +0800 RDMA/hns: Fix soft lockup under heavy CEQE load [ Upstream commit 2fdf34038369c0a27811e7b4680662a14ada1d6b ] CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9b812436f03e3c388fa32cd1cc93f7113a9840eb Author: Junxian Huang Date: Wed Jul 10 21:36:58 2024 +0800 RDMA/hns: Check atomic wr length [ Upstream commit 6afa2c0bfb8ef69f65715ae059e5bd5f9bbaf03b ] 8 bytes is the only supported length of atomic. Add this check in set_rc_wqe(). Besides, stop processing WQEs and return from set_rc_wqe() if there is any error. Fixes: 384f88185112 ("RDMA/hns: Add atomic support") Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240710133705.896445-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9210853b0c52948a02f891fe4f79e44593ec9949 Author: Nick Bowler Date: Wed Jul 10 23:54:17 2024 -0400 macintosh/therm_windtunnel: fix module unload. [ Upstream commit fd748e177194ebcbbaf98df75152a30e08230cc6 ] The of_device_unregister call in therm_windtunnel's module_exit procedure does not fully reverse the effects of of_platform_device_create in the module_init prodedure. Once you unload this module, it is impossible to load it ever again since only the first of_platform_device_create call on the fan node succeeds. This driver predates first git commit, and it turns out back then of_platform_device_create worked differently than it does today. So this is actually an old regression. The appropriate function to undo of_platform_device_create now appears to be of_platform_device_destroy, and switching to use this makes it possible to unload and load the module as expected. Signed-off-by: Nick Bowler Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Signed-off-by: Michael Ellerman Link: https://msgid.link/20240711035428.16696-1-nbowler@draconx.ca Signed-off-by: Sasha Levin commit dd479933722ec99825afca078076aacf52ce9ccf Author: Michael Ellerman Date: Thu May 9 22:12:47 2024 +1000 powerpc/xmon: Fix disassembly CPU feature checks [ Upstream commit 14196e47c5ffe32af7ed5a51c9e421c5ea5bccce ] In the xmon disassembly code there are several CPU feature checks to determine what dialects should be passed to the disassembler. The dialect controls which instructions the disassembler will recognise. Unfortunately the checks are incorrect, because instead of passing a single CPU feature they are passing a mask of feature bits. For example the code: if (cpu_has_feature(CPU_FTRS_POWER5)) dialect |= PPC_OPCODE_POWER5; Is trying to check if the system is running on a Power5 CPU. But CPU_FTRS_POWER5 is a mask of *all* the feature bits that are enabled on a Power5. In practice the test will always return true for any 64-bit CPU, because at least one bit in the mask will be present in the CPU_FTRS_ALWAYS mask. Similarly for all the other checks against CPU_FTRS_xx masks. Rather than trying to match the disassembly behaviour exactly to the current CPU, just differentiate between 32-bit and 64-bit, and Altivec, VSX and HTM. That will cause some instructions to be shown in disassembly even on a CPU that doesn't support them, but that's OK, objdump -d output has the same behaviour, and if anything it's less confusing than some instructions not being disassembled. Fixes: 897f112bb42e ("[POWERPC] Import updated version of ppc disassembly code for xmon") Signed-off-by: Michael Ellerman Link: https://msgid.link/20240509121248.270878-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 7e686c35fad0c9c7c550c9af3aa23c0c6e2ae148 Author: Lu Baolu Date: Tue Jul 9 23:26:43 2024 +0800 iommu/vt-d: Fix aligned pages in calculate_psi_aligned_address() [ Upstream commit 0a3f6b3463014b03f6ad10eacc4d1d9af75d54a1 ] The helper calculate_psi_aligned_address() is used to convert an arbitrary range into a size-aligned one. The aligned_pages variable is calculated from input start and end, but is not adjusted when the start pfn is not aligned and the mask is adjusted, which results in an incorrect number of pages returned. The number of pages is used by qi_flush_piotlb() to flush caches for the first-stage translation. With the wrong number of pages, the cache is not synchronized, leading to inconsistencies in some cases. Fixes: c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240709152643.28109-3-baolu.lu@linux.intel.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 497a8fdd1e5c122c5dde14c4e9090e5e975b7258 Author: Lu Baolu Date: Tue Jul 9 23:26:42 2024 +0800 iommu/vt-d: Limit max address mask to MAX_AGAW_PFN_WIDTH [ Upstream commit c420a2b4e8be06f16f3305472bd25a1dd12059ec ] Address mask specifies the number of low order bits of the address field that must be masked for the invalidation operation. Since address bits masked start from bit 12, the max address mask should be MAX_AGAW_PFN_WIDTH, as defined in Table 19 ("Invalidate Descriptor Address Mask Encodings") of the spec. Limit the max address mask returned from calculate_psi_aligned_address() to MAX_AGAW_PFN_WIDTH to prevent potential integer overflow in the following code: qi_flush_dev_iotlb(): ... addr |= (1ULL << (VTD_PAGE_SHIFT + mask - 1)) - 1; ... Fixes: c4d27ffaa8eb ("iommu/vt-d: Add cache tag invalidation helpers") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240709152643.28109-2-baolu.lu@linux.intel.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit a08b8b144cc79c03568ca6d4dd2936a917ed9dd1 Author: Frank Li Date: Fri Apr 12 12:08:41 2024 -0400 PCI: dwc: Fix index 0 incorrectly being interpreted as a free ATU slot [ Upstream commit c2a57ee0f2f1ad8c970ff58b78a43e85abbdeb7f ] When PERST# assert and deassert happens on the PERST# supported platforms, both iATU0 and iATU6 will map inbound window to BAR0. DMA will access the area that was previously allocated (iATU0) for BAR0, instead of the new area (iATU6) for BAR0. Right now, this isn't an issue because both iATU0 and iATU6 should translate inbound accesses to BAR0 to the same allocated memory area. However, having two separate inbound mappings for the same BAR is a disaster waiting to happen. The mappings between PCI BAR and iATU inbound window are maintained in the dw_pcie_ep::bar_to_atu[] array. While allocating a new inbound iATU map for a BAR, dw_pcie_ep_inbound_atu() API checks for the availability of the existing mapping in the array and if it is not found (i.e., value in the array indexed by the BAR is found to be 0), it allocates a new map value using find_first_zero_bit(). The issue is the existing logic failed to consider the fact that the map value '0' is a valid value for BAR0, so find_first_zero_bit() will return '0' as the map value for BAR0 (note that it returns the first zero bit position). Due to this, when PERST# assert + deassert happens on the PERST# supported platforms, the inbound window allocation restarts from BAR0 and the existing logic to find the BAR mapping will return '6' for BAR0 instead of '0' due to the fact that it considers '0' as an invalid map value. Fix this issue by always incrementing the map value before assigning to bar_to_atu[] array and then decrementing it while fetching. This will make sure that the map value '0' always represents the invalid mapping." Fixes: 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") Closes: https://lore.kernel.org/linux-pci/ZXsRp+Lzg3x%2Fnhk3@x1-carbon/ Link: https://lore.kernel.org/linux-pci/20240412160841.925927-1-Frank.Li@nxp.com Reported-by: Niklas Cassel Tested-by: Niklas Cassel Signed-off-by: Frank Li Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit 66363bc6ff3eb1c5e644989141eb97d5a1fa9a94 Author: Manivannan Sadhasivam Date: Tue Apr 30 11:43:42 2024 +0530 PCI: qcom-ep: Disable resources unconditionally during PERST# assert [ Upstream commit 912315715d7b74f7abdb6f063ebace44ee288af9 ] All EP specific resources are enabled during PERST# deassert. As a counter operation, all resources should be disabled during PERST# assert. There is no point in skipping that if the link was not enabled. This will also result in enablement of the resources twice if PERST# got deasserted again. So remove the check from qcom_pcie_perst_assert() and disable all the resources unconditionally. Fixes: f55fee56a631 ("PCI: qcom-ep: Add Qualcomm PCIe Endpoint controller driver") Link: https://lore.kernel.org/linux-pci/20240430-pci-epf-rework-v4-1-22832d0d456f@linaro.org Tested-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit aceabb0c074a2930776e7a50ac2d497837c1fba1 Author: Dominique Martinet Date: Fri Jul 5 16:48:30 2024 +0900 MIPS: Octeron: remove source file executable bit [ Upstream commit 89c7f5078935872cf47a713a645affb5037be694 ] This does not matter the least, but there is no other .[ch] file in the repo that is executable, so clean this up. Fixes: 29b83a64df3b ("MIPS: Octeon: Add PCIe link status check") Signed-off-by: Dominique Martinet Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit f6f2e9c208a65c89837c55c8c6077578a399e6ad Author: Lorenzo Bianconi Date: Mon Jun 17 11:25:49 2024 +0200 clk: en7523: fix rate divider for slic and spi clocks [ Upstream commit 58c53d43142f222221e5a76a7016c4d8f3b84b97 ] Introduce div_offset field in en_clk_desc struct in order to fix rate divider estimation in en7523_get_div routine for slic and spi fixed rate clocks. Moreover, fix base_shift for crypto clock. Fixes: 1e6273179190 ("clk: en7523: Add clock driver for Airoha EN7523 SoC") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/c491bdea05d847f1f1294b94f14725d292eb95d0.1718615934.git.lorenzo@kernel.org Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b5bdb36e7ccf9b3a8f06f001a4fb993b584c4fe4 Author: Stephen Boyd Date: Thu May 2 15:47:02 2024 -0700 clk: qcom: Park shared RCGs upon registration [ Upstream commit 01a0a6cc8cfd9952e72677d48d56cf6bc4e3a561 ] There's two problems with shared RCGs. The first problem is that they incorrectly report the parent after commit 703db1f5da1e ("clk: qcom: rcg2: Cache CFG register updates for parked RCGs"). That's because the cached CFG register value needs to be populated when the clk is registered. clk_rcg2_shared_enable() writes the cached CFG register value 'parked_cfg'. This value is initially zero due to static initializers. If a driver calls clk_enable() before setting a rate or parent, it will set the parent to '0' which is (almost?) always XO, and may not reflect the parent at registration. In the worst case, this switches the RCG from sourcing a fast PLL to the slow crystal speed. The second problem is that the force enable bit isn't cleared. The force enable bit is only used during parking and unparking of shared RCGs. Otherwise it shouldn't be set because it keeps the RCG enabled even when all the branches on the output of the RCG are disabled (the hardware has a feedback mechanism so that any child branches keep the RCG enabled when the branch enable bit is set). This problem wastes power if the clk is unused, and is harmful in the case that the clk framework disables the parent of the force enabled RCG. In the latter case, the GDSC the shared RCG is associated with will get wedged if the RCG's source clk is disabled and the GDSC tries to enable the RCG to do "housekeeping" while powering on. Both of these problems combined with incorrect runtime PM usage in the display driver lead to a black screen on Qualcomm sc7180 Trogdor chromebooks. What happens is that the bootloader leaves the 'disp_cc_mdss_rot_clk' enabled and the 'disp_cc_mdss_rot_clk_src' force enabled and parented to 'disp_cc_pll0'. The mdss driver probes and runtime suspends, disabling the mdss_gdsc which uses the 'disp_cc_mdss_rot_clk_src' for "housekeeping". The 'disp_cc_mdss_rot_clk' is disabled during late init because the clk is unused, but the parent 'disp_cc_mdss_rot_clk_src' is still force enabled because the force enable bit was never cleared. Then 'disp_cc_pll0' is disabled because it is also unused. That's because the clk framework believes the parent of the RCG is XO when it isn't. A child device of the mdss device (e.g. DSI) runtime resumes mdss which powers on the mdss_gdsc. This wedges the GDSC because 'disp_cc_mdss_rot_clk_src' is parented to 'disp_cc_pll0' and that PLL is off. With the GDSC wedged, mdss_runtime_resume() tries to enable 'disp_cc_mdss_mdp_clk' but it can't because the GDSC has wedged all the clks associated with the GDSC causing clks to stay stuck off. This leads to the following warning seen at boot and a black screen because the display driver fails to probe. disp_cc_mdss_mdp_clk status stuck at 'off' WARNING: CPU: 1 PID: 81 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x114/0x168 Modules linked in: CPU: 1 PID: 81 Comm: kworker/u16:4 Not tainted 6.7.0-g0dd3ee311255 #1 f5757d475795053fd2ad52247a070cd50dd046f2 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_branch_toggle+0x114/0x168 lr : clk_branch_toggle+0x110/0x168 sp : ffffffc08084b670 pmr_save: 00000060 x29: ffffffc08084b680 x28: ffffff808006de00 x27: 0000000000000001 x26: ffffff8080dbd4f4 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000000 x22: ffffffd838461198 x21: ffffffd838007997 x20: ffffffd837541d5c x19: 0000000000000001 x18: 0000000000000004 x17: 0000000000000000 x16: 0000000000000010 x15: ffffffd837070fac x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001 x11: c0000000ffffdfff x10: ffffffd838347aa0 x9 : 08dadf92e516c000 x8 : 08dadf92e516c000 x7 : 0000000000000000 x6 : 0000000000000027 x5 : ffffffd8385a61f2 x4 : 0000000000000000 x3 : ffffffc08084b398 x2 : ffffffc08084b3a0 x1 : 00000000ffffdfff x0 : 00000000fffffff0 Call trace: clk_branch_toggle+0x114/0x168 clk_branch2_enable+0x24/0x30 clk_core_enable+0x5c/0x1c8 clk_enable+0x38/0x58 clk_bulk_enable+0x40/0xb0 mdss_runtime_resume+0x68/0x258 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0x124/0x214 __rpm_callback+0x7c/0x15c rpm_callback+0x30/0x88 rpm_resume+0x390/0x4d8 rpm_resume+0x43c/0x4d8 __pm_runtime_resume+0x54/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x48/0xa4 device_add+0x52c/0x6fc mipi_dsi_device_register_full+0x104/0x1a8 devm_mipi_dsi_device_register_full+0x28/0x78 ti_sn_bridge_probe+0x1dc/0x2bc auxiliary_bus_probe+0x4c/0x94 really_probe+0xf8/0x270 __driver_probe_device+0xa8/0x130 driver_probe_device+0x44/0x104 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x94/0xe8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x48/0xa4 deferred_probe_work_func+0x9c/0xd8 Fix these problems by parking shared RCGs at boot. This will properly initialize the parked_cfg struct member so that the parent is reported properly and ensure that the clk won't get stuck on or off because the RCG is parented to the safe source (XO). Fixes: 703db1f5da1e ("clk: qcom: rcg2: Cache CFG register updates for parked RCGs") Reported-by: Stephen Boyd Closes: https://lore.kernel.org/r/1290a5a0f7f584fcce722eeb2a1fd898.sboyd@kernel.org Closes: https://issuetracker.google.com/319956935 Reported-by: Laura Nao Closes: https://lore.kernel.org/r/20231218091806.7155-1-laura.nao@collabora.com Cc: Bjorn Andersson Cc: Dmitry Baryshkov Cc: Douglas Anderson Cc: Taniya Das Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20240502224703.103150-1-swboyd@chromium.org Reviewed-by: Douglas Anderson Tested-by: Nícolas F. R. A. Prado Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 3717b094aa727481232a4da02b1269ee52205087 Author: Abel Vesa Date: Thu May 30 17:05:24 2024 +0300 clk: qcom: gcc-x1e80100: Set parent rate for USB3 sec and tert PHY pipe clks [ Upstream commit 14539c88972bd984f1f04c9e601c1a2835d3e5d2 ] Allow the USB3 second and third GCC PHY pipe clocks to propagate the rate to the pipe clocks provided by the QMP combo PHYs. The first instance is already doing that. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Abel Vesa Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240530-x1e80100-clk-gcc-usb3-sec-tert-set-parent-rate-v1-1-7b2b04cad545@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a3889e012f7df86e0a475e53c1fad884d99ce741 Author: Chen Ni Date: Thu Jul 4 15:36:06 2024 +0800 clk: qcom: kpss-xcc: Return of_clk_add_hw_provider to transfer the error [ Upstream commit 9db4585eca22fcd0422a94ac792f87dcbf74b643 ] Return of_clk_add_hw_provider() in order to transfer the error if it fails. Fixes: 09be1a39e685 ("clk: qcom: kpss-xcc: register it as clk provider") Signed-off-by: Chen Ni Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240704073606.1976936-1-nichen@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8a2694a0cad71c9f9839a7043439d6e74b636455 Author: Nivas Varadharajan Mugunthakumar Date: Tue Jun 25 15:38:50 2024 +0100 crypto: qat - extend scope of lock in adf_cfg_add_key_value_param() [ Upstream commit 6424da7d8b938fe66e7e771eaa949bc7b6c29c00 ] The function adf_cfg_add_key_value_param() attempts to access and modify the key value store of the driver without locking. Extend the scope of cfg->lock to avoid a potential race condition. Fixes: 92bf269fbfe9 ("crypto: qat - change behaviour of adf_cfg_add_key_value_param()") Signed-off-by: Nivas Varadharajan Mugunthakumar Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 728ca88a7e9820c9a312d92446a2cc1b8aa91544 Author: Heiko Stuebner Date: Fri Jul 5 08:48:41 2024 +0100 nvmem: rockchip-otp: set add_legacy_fixed_of_cells config option [ Upstream commit 2933e79db3c00a8cdc56f6bb050a857fec1875ad ] The Rockchip OTP describes its layout via devicetree subnodes, so set the appropriate property. Fixes: 2cc3b37f5b6d ("nvmem: add explicit config option to read old syntax fixed OF cells") Signed-off-by: Heiko Stuebner Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20240705074852.423202-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9fd003f344d502f65252963169df3dd237054e49 Author: Justin Tee Date: Fri Jun 28 10:20:10 2024 -0700 scsi: lpfc: Revise lpfc_prep_embed_io routine with proper endian macro usages [ Upstream commit 8bc7c617642db6d8d20ee671fb6c4513017e7a7e ] On big endian architectures, it is possible to run into a memory out of bounds pointer dereference when FCP targets are zoned. In lpfc_prep_embed_io, the memcpy(ptr, fcp_cmnd, sgl->sge_len) is referencing a little endian formatted sgl->sge_len value. So, the memcpy can cause big endian systems to crash. Redefine the *sgl ptr as a struct sli4_sge_le to make it clear that we are referring to a little endian formatted data structure. And, update the routine with proper le32_to_cpu macro usages. Fixes: af20bb73ac25 ("scsi: lpfc: Add support for 32 byte CDBs") Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240628172011.25921-8-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e9164903b8b303c34723177b02fe91e49e3c4cd7 Author: Denis Arefev Date: Thu Jun 13 12:54:48 2024 +0300 net: missing check virtio [ Upstream commit e269d79c7d35aa3808b1f3c1737d63dab504ddc8 ] Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again 1. After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help. 2. The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder. offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Found by Linux Verification Center (linuxtesting.org) with Syzkaller Fixes: 0f6925b3e8da ("virtio_net: Do not pull payload in skb->head") Signed-off-by: Denis Arefev Message-Id: <20240613095448.27118-1-arefev@swemel.ru> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit eab96e8716cbfc2834b54f71cc9501ad4eec963b Author: Michael S. Tsirkin Date: Mon Apr 22 10:03:13 2024 -0400 vhost/vsock: always initialize seqpacket_allow [ Upstream commit 1e1fdcbdde3b7663e5d8faeb2245b9b151417d22 ] There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features Reported-by: syzbot+6c21aeb59d0e82eb2782@syzkaller.appspotmail.com Reported-by: Jeongjun Park Fixes: ced7b713711f ("vhost/vsock: support SEQPACKET for transport"). Tested-by: Arseny Krasnov Cc: David S. Miller Cc: Stefan Hajnoczi Message-ID: <20240422100010-mutt-send-email-mst@kernel.org> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Stefano Garzarella Reviewed-by: Eugenio Pérez Acked-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 55237ec25ed59ee15df761ea2fad3d88f5c1163d Author: Dan Carpenter Date: Mon Jun 10 12:33:49 2024 +0300 PCI: endpoint: Fix error handling in epf_ntb_epc_cleanup() [ Upstream commit 6bba3c0ac5dc54737998a0982b2e272242c87e0f ] There are two issues related to epf_ntb_epc_cleanup(): 1) It should call epf_ntb_config_sspad_bar_clear() 2) The epf_ntb_bind() function should call epf_ntb_epc_cleanup() to cleanup. I also changed the ordering a bit. Unwinding should be done in the mirror order from how they are allocated. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Link: https://lore.kernel.org/linux-pci/aaffbe8d-7094-4083-8146-185f4a84e8a1@moroto.mountain Signed-off-by: Dan Carpenter Signed-off-by: Krzysztof Wilczyński Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit b9e8695246bcfc028341470cbf92630cdc1ba36b Author: Dan Carpenter Date: Mon Jun 10 12:33:39 2024 +0300 PCI: endpoint: Clean up error handling in vpci_scan_bus() [ Upstream commit 8e0f5a96c534f781e8c57ca30459448b3bfe5429 ] Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Link: https://lore.kernel.org/linux-pci/68e0f6a4-fd57-45d0-945b-0876f2c8cb86@moroto.mountain Signed-off-by: Dan Carpenter Signed-off-by: Krzysztof Wilczyński Reviewed-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 4275b46b75731910d771bbe89ef40cb04230c002 Author: Georgi Djakov Date: Wed Jul 3 18:07:59 2024 -0700 iommu/arm-smmu-qcom: Register the TBU driver in qcom_smmu_impl_init [ Upstream commit 0b4eeee2876f2b08442eb32081451bf130e01a4c ] Currently the TBU driver will only probe when CONFIG_ARM_SMMU_QCOM_DEBUG is enabled. The driver not probing would prevent the platform to reach sync_state and the system will remain in sub-optimal power consumption mode while waiting for all consumer drivers to probe. To address this, let's register the TBU driver in qcom_smmu_impl_init(), so that it can probe, but still enable its functionality only when the debug option in Kconfig is enabled. Reported-by: Dmitry Baryshkov Closes: https://lore.kernel.org/r/CAA8EJppcXVu72OSo+OiYEiC1HQjP3qCwKMumOsUhcn6Czj0URg@mail.gmail.com Fixes: 414ecb030870 ("iommu/arm-smmu-qcom-debug: Add support for TBUs") Signed-off-by: Georgi Djakov Link: https://lore.kernel.org/r/20240704010759.507798-1-quic_c_gdjako@quicinc.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b1173d64edd276c957b6d09e1f971c85b38f1519 Author: Aleksandr Mishin Date: Wed Jul 3 22:10:07 2024 +0300 ASoC: amd: Adjust error handling in case of absent codec device [ Upstream commit 5080808c3339de2220c602ab7c7fa23dc6c1a5a3 ] acpi_get_first_physical_node() can return NULL in several cases (no such device, ACPI table error, reference count drop to 0, etc). Existing check just emit error message, but doesn't perform return. Then this NULL pointer is passed to devm_acpi_dev_add_driver_gpios() where it is dereferenced. Adjust this error handling by adding error code return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 02527c3f2300 ("ASoC: amd: add Machine driver for Jadeite platform") Signed-off-by: Aleksandr Mishin Link: https://patch.msgid.link/20240703191007.8524-1-amishin@t-argos.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f2ff6935b6dee494d1cbaad74418889c3388aac Author: Guenter Roeck Date: Sat Jun 29 10:37:15 2024 -0700 eeprom: ee1004: Call i2c_new_scanned_device to instantiate thermal sensor [ Upstream commit 249b4deaff71cfc6ac9a8e436af876be6d84052b ] Instantiating a device by calling i2c_new_client_device() assumes that the device is not already instantiated. If that is not the case, it will return an error and generate a misleading kernel log message. i2c i2c-0: Failed to register i2c client jc42 at 0x18 (-16) This can be reproduced by unloading the ee1004 driver and loading it again. Avoid this by calling i2c_new_scanned_device() instead, which returns silently if a device is already instantiated or does not exist. Fixes: 393bd1000f81 ("eeprom: ee1004: add support for temperature sensor") Cc: Heiner Kallweit Cc: Thomas Weißschuh Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20240629173716.20389-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 49c9945c054df4c22008e2bf87ca74d3e2507aa6 Author: Christoph Schlameuss Date: Mon Jun 24 11:59:02 2024 +0200 kvm: s390: Reject memory region operations for ucontrol VMs [ Upstream commit 7816e58967d0e6cadce05c8540b47ed027dc2499 ] This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP. Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2. Signed-off-by: Christoph Schlameuss Fixes: 27e0393f15fc ("KVM: s390: ucontrol: per vcpu address spaces") Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20240624095902.29375-1-schlameuss@linux.ibm.com Signed-off-by: Janosch Frank [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix] Message-ID: <20240624095902.29375-1-schlameuss@linux.ibm.com> Signed-off-by: Sasha Levin commit a5c15a78c0e1631b7df822b56e8b6424e4d1ca3e Author: Benjamin Marzinski Date: Tue Jul 2 17:02:48 2024 +0200 dm-raid: Fix WARN_ON_ONCE check for sync_thread in raid_resume [ Upstream commit 3199a34bfaf7561410e0be1e33a61eba870768fc ] rm-raid devices will occasionally trigger the following warning when being resumed after a table load because DM_RECOVERY_RUNNING is set: WARNING: CPU: 7 PID: 5660 at drivers/md/dm-raid.c:4105 raid_resume+0xee/0x100 [dm_raid] The failing check is: WARN_ON_ONCE(test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)); This check is designed to make sure that the sync thread isn't registered, but md_check_recovery can set MD_RECOVERY_RUNNING without the sync_thread ever getting registered. Instead of checking if MD_RECOVERY_RUNNING is set, check if sync_thread is non-NULL. Fixes: 16c4770c75b1 ("dm-raid: really frozen sync_thread during suspend") Suggested-by: Yu Kuai Signed-off-by: Benjamin Marzinski Reviewed-by: Yu Kuai Signed-off-by: Mikulas Patocka Signed-off-by: Sasha Levin commit 298feddffbfc3a3983465dcded466c8bb47bb985 Author: Abel Vesa Date: Fri Jun 28 11:08:00 2024 +0300 clk: qcom: gcc-x1e80100: Fix halt_check for all pipe clocks [ Upstream commit f27e42c7d3ff8ddfc57273efd1e8642ea89bad90 ] In case of all pipe clocks, there is a QMP PHY clock that is feeding them. If, for whatever reason, the clock from the PHY is not enabled, halt bit will not get set, and the clock controller driver will assume the clock is stuck in a specific state. The way this is supposed to be properly fixed is to defer the checking of the halt bit until after the PHY clock has been initialized, but doing so complicates the clock controller driver. In fact, since these pipe clocks are consumed by the PHY, while the PHY is also the one providing the source, if clock gets stuck, the PHY driver would be to blame. So instead of checking the halt bit in here, just skip it and assume the PHY driver is handling the source clock correctly. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Signed-off-by: Abel Vesa Reviewed-by: Taniya Das Link: https://lore.kernel.org/r/20240628-x1e80100-clk-gcc-fix-halt-check-for-usb-phy-pipe-clks-v2-1-db3be54b1143@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 899bb519f2a9e83645eb94871992f4e689131b21 Author: Dmitry Torokhov Date: Thu Jun 6 23:02:48 2024 -0700 Input: elan_i2c - do not leave interrupt disabled on suspend failure [ Upstream commit 5f82c1e04721e7cd98e604eb4e58f0724d8e5a65 ] Make sure interrupts are not left disabled when we fail to suspend the touch controller. Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad") Link: https://lore.kernel.org/r/ZmKiiL-1wzKrhqBj@google.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 4adabd438382d75e9c4a1a1f830cfcb048d3a1bc Author: Leon Romanovsky Date: Mon Jun 24 16:24:32 2024 +0300 RDMA/device: Return error earlier if port in not valid [ Upstream commit 917918f57a7b139c043e78c502876f2c286f4f0a ] There is no need to allocate port data if port provided is not valid. Fixes: c2261dd76b54 ("RDMA/device: Add ib_device_set_netdev() as an alternative to get_netdev") Link: https://lore.kernel.org/r/022047a8b16988fc88d4426da50bf60a4833311b.1719235449.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e4e11a6ed2a8a9aa7b173d8b7b02c6db3351dc1f Author: Arnd Bergmann Date: Wed May 29 11:50:39 2024 +0200 mtd: make mtd_test.c a separate module [ Upstream commit a5cf054d325e6f362e82fe6d124a1871a4af8174 ] This file gets linked into nine different modules, which causes a warning: scripts/Makefile.build:236: drivers/mtd/tests/Makefile: mtd_test.o is added to multiple modules: mtd_nandbiterrs mtd_oobtest mtd_pagetest mtd_readtest mtd_speedtest mtd_stresstest mtd_subpagetest mtd_torturetest Make it a separate module instead. Fixes: a995c792280d ("mtd: tests: rename sources in order to link a helper object") Signed-off-by: Arnd Bergmann Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240529095049.1915393-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 0036f27f2a7b4bd7c77ca1471c0e34dc393c5acb Author: Joao Martins Date: Thu Jun 27 12:01:00 2024 +0100 iommufd/iova_bitmap: Check iova_bitmap_done() after set ahead [ Upstream commit 792583656f554e35383d6b2325371c8fe056a56b ] After iova_bitmap_set_ahead() returns it may be at the end of the range. Move iova_bitmap_set_ahead() earlier to avoid unnecessary attempt in trying to pin the next pages by reusing iova_bitmap_done() check. Fixes: 2780025e01e2 ("iommufd/iova_bitmap: Handle recording beyond the mapped pages") Link: https://lore.kernel.org/r/20240627110105.62325-7-joao.m.martins@oracle.com Signed-off-by: Joao Martins Reviewed-by: Kevin Tian Tested-by: Matt Ochs Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1d779d0e4e8fee90b7ed9315b9ae12afde5cdc1c Author: Joao Martins Date: Thu Jun 27 12:00:58 2024 +0100 iommufd/selftest: Fix tests to use MOCK_PAGE_SIZE based buffer sizes [ Upstream commit ffa3c799ce157493615f9f3c2b3c9ba602d320b9 ] commit a9af47e382a4 ("iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_BITMAP") added tests covering edge cases in the boundaries of iova bitmap. Although it used buffer sizes thinking in PAGE_SIZE (4K) as opposed to the MOCK_PAGE_SIZE (2K) that is used in iommufd mock selftests. This meant that isn't correctly exercising everything specifically the u32 and 4K bitmap test cases. Fix selftests buffer sizes to be based on mock page size. Link: https://lore.kernel.org/r/20240627110105.62325-5-joao.m.martins@oracle.com Reported-by: Kevin Tian Closes: https://lore.kernel.org/linux-iommu/96efb6cf-a41c-420f-9673-2f0b682cac8c@oracle.com/ Fixes: a9af47e382a4 ("iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_BITMAP") Signed-off-by: Joao Martins Reviewed-by: Kevin Tian Tested-by: Matt Ochs Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b06d34eb8fcd9a3ba5b1546af209a6da0c127193 Author: Joao Martins Date: Thu Jun 27 12:00:57 2024 +0100 iommufd/selftest: Add tests for <= u8 bitmap sizes [ Upstream commit 33335584eb78c0bda21ff8d759c39e035abb48ac ] Add more tests for bitmaps smaller than or equal to an u8, though skip the tests if the IOVA buffer size is smaller than the mock page size. Link: https://lore.kernel.org/r/20240627110105.62325-4-joao.m.martins@oracle.com Signed-off-by: Joao Martins Reviewed-by: Kevin Tian Tested-by: Matt Ochs Signed-off-by: Jason Gunthorpe Stable-dep-of: ffa3c799ce15 ("iommufd/selftest: Fix tests to use MOCK_PAGE_SIZE based buffer sizes") Signed-off-by: Sasha Levin commit 73dc9fb2b38de2bdf42e29fe5a4ac3ff6ad30e06 Author: Joao Martins Date: Thu Jun 27 12:00:56 2024 +0100 iommufd/selftest: Fix iommufd_test_dirty() to handle Fixes: a9af47e382a4 ("iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_BITMAP") Signed-off-by: Joao Martins Reviewed-by: Kevin Tian Tested-by: Matt Ochs Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2355c5321732f80f9f2acd3b235c2cf0c0cd1475 Author: Joao Martins Date: Thu Jun 27 12:00:55 2024 +0100 iommufd/selftest: Fix dirty bitmap tests with u8 bitmaps [ Upstream commit ec61f820a2ff07d1717583bd57d6ee45d2763a6e ] With 64k base pages, the first 128k iova length test requires less than a byte for a bitmap, exposing a bug in the tests that assume that bitmaps are at least a byte. Rather than dealing with bytes, have _test_mock_dirty_bitmaps() pass the number of bits. The caller functions are adjusted to also use bits as well, and converting to bytes when clearing, allocating and freeing the bitmap. Link: https://lore.kernel.org/r/20240627110105.62325-2-joao.m.martins@oracle.com Reported-by: Matt Ochs Fixes: a9af47e382a4 ("iommufd/selftest: Test IOMMU_HWPT_GET_DIRTY_BITMAP") Signed-off-by: Joao Martins Reviewed-by: Kevin Tian Tested-by: Matt Ochs Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 57a6e7619ceac8e9dbf574830ab11a86709cc33a Author: Chen Ni Date: Fri Jun 28 16:05:34 2024 +0800 ASoC: max98088: Check for clk_prepare_enable() error [ Upstream commit 1a70579723fde3624a72dfea6e79e55be6e36659 ] clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Fixes: 62a7fc32a628 ("ASoC: max98088: Add master clock handling") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20240628080534.843815-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cc3c0d2784be58fdf13bad05b5e673e33da40dc5 Author: Nathan Lynch Date: Mon Jun 3 07:36:55 2024 -0500 powerpc/prom: Add CPU info to hardware description string later [ Upstream commit 7bdd1c6c87de758750d419eedab7285b95b66417 ] cur_cpu_spec->cpu_name is appended to ppc_hw_desc before cur_cpu_spec has taken on its final value. This is illustrated on pseries by comparing the CPU name as reported at boot ("POWER8E (raw)") to the contents of /proc/cpuinfo ("POWER8 (architected)"): $ dmesg | grep Hardware Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 \ of:IBM,FW860.50 (SV860_146) hv:phyp pSeries $ grep -m 1 ^cpu /proc/cpuinfo cpu : POWER8 (architected), altivec supported Some 44x models would appear to be affected as well; see identical_pvr_fixup(). This results in incorrect CPU information in stack dumps -- ppc_hw_desc is an input to dump_stack_set_arch_desc(). Delay gathering the CPU name until after all potential calls to identify_cpu(). Signed-off-by: Nathan Lynch Fixes: bd649d40e0f2 ("powerpc: Add PVR & CPU name to hardware description") Signed-off-by: Michael Ellerman Link: https://msgid.link/20240603-fix-cpu-hwdesc-v1-1-945f2850fcaa@linux.ibm.com Signed-off-by: Sasha Levin commit c2fa93051fdcdbb9764a15425f6b873205f1999f Author: Harald Freudenberger Date: Fri Jun 21 17:02:24 2024 +0200 hwrng: core - Fix wrong quality calculation at hw rng registration [ Upstream commit 95c0f5c3b8bb7acdc5c4f04bc6a7d3f40d319e9e ] When there are rng sources registering at the hwrng core via hwrng_register() a struct hwrng is delivered. There is a quality field in there which is used to decide which of the registered hw rng sources will be used by the hwrng core. With commit 16bdbae39428 ("hwrng: core - treat default_quality as a maximum and default to 1024") there came in a new default of 1024 in case this field is empty and all the known hw rng sources at that time had been reworked to not fill this field and thus use the default of 1024. The code choosing the 'better' hw rng source during registration of a new hw rng source has never been adapted to this and thus used 0 if the hw rng implementation does not fill the quality field. So when two rng sources register, one with 0 (meaning 1024) and the other one with 999, the 999 hw rng will be chosen. As the later invoked function hwrng_init() anyway adjusts the quality field of the hw rng source, this adjustment is now done during registration of this new hw rng source. Tested on s390 with two hardware rng sources: crypto cards and trng true random generator device driver. Fixes: 16bdbae39428 ("hwrng: core - treat default_quality as a maximum and default to 1024") Reported-by: Christian Rund Suggested-by: Herbert Xu Signed-off-by: Harald Freudenberger Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 45b2a23e00d448a9e6d1f371ca3a4d4b073fe78c Author: Huai-Yuan Liu Date: Fri Jun 21 16:25:45 2024 +0800 scsi: lpfc: Fix a possible null pointer dereference [ Upstream commit 5e0bf3e8aec2cbc51123f84b29aaacbd91fc56fa ] In function lpfc_xcvr_data_show, the memory allocation with kmalloc might fail, thereby making rdp_context a null pointer. In the following context and functions that use this pointer, there are dereferencing operations, leading to null pointer dereference. To fix this issue, a null pointer check should be added. If it is null, use scnprintf to notify the user and return len. Fixes: 479b0917e447 ("scsi: lpfc: Create a sysfs entry called lpfc_xcvr_data for transceiver info") Signed-off-by: Huai-Yuan Liu Link: https://lore.kernel.org/r/20240621082545.449170-1-qq810974084@gmail.com Reviewed-by: Justin Tee Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 577eac91b2a2be7ddd80bcea132eea6b8f731c0b Author: Aleksandr Mishin Date: Wed Jun 5 13:49:53 2024 +0300 ASoC: qcom: Adjust issues in case of DT error in asoc_qcom_lpass_cpu_platform_probe() [ Upstream commit f9f7f29f64454bb20896c7d918c3abc3a1aa487b ] If IORESOURCE_MEM "lpass-rxtx-cdc-dma-lpm" or "lpass-va-cdc-dma-lpm" resources is not provided in Device Tree due to any error, platform_get_resource_byname() will return NULL which is later dereferenced. According to sound/qcom,lpass-cpu.yaml, these resources are provided, but DT can be broken due to any error. In such cases driver must be able to protect itself, since the DT is external data for the driver. Adjust this issues by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: b138706225c9 ("ASoC: qcom: Add regmap config support for codec dma driver") Signed-off-by: Aleksandr Mishin Link: https://patch.msgid.link/20240605104953.12072-1-amishin@t-argos.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 498766fc3e51f8f862aa1ef5caad7a4dd3db5183 Author: Honggang LI Date: Mon Jun 24 10:03:48 2024 +0800 RDMA/rxe: Don't set BTH_ACK_MASK for UC or UD QPs [ Upstream commit 4adcaf969d77d3d3aa3871bbadc196258a38aec6 ] BTH_ACK_MASK bit is used to indicate that an acknowledge (for this packet) should be scheduled by the responder. Both UC and UD QPs are unacknowledged, so don't set BTH_ACK_MASK for UC or UD QPs. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Honggang LI Link: https://lore.kernel.org/r/20240624020348.494338-1-honggangli@163.com Reviewed-by: Zhu Yanjun Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c2ac6edfc9199ab5d93b98186a236bbd1f6b93db Author: Or Har-Toov Date: Sun Jun 16 19:10:36 2024 +0300 RDMA/mlx5: Use sq timestamp as QP timestamp when RoCE is disabled [ Upstream commit 0c5275bf75ec3708d95654195ae4ed80d946d088 ] When creating a QP, one of the attributes is TS format (timestamp). In some devices, we have a limitation that all QPs should have the same ts_format. The ts_format is chosen based on the device's capability. The qp_ts_format cap resides under the RoCE caps table, and the cap will be 0 when RoCE is disabled. So when RoCE is disabled, the value that should be queried is sq_ts_format under HCA caps. Consider the case when the system supports REAL_TIME_TS format (0x2), some QPs are created with REAL_TIME_TS as ts_format, and afterwards RoCE gets disabled. When trying to construct a new QP, we can't use the qp_ts_format, that is queried from the RoCE caps table, Since it leads to passing 0x0 (FREE_RUNNING_TS) as the value of the qp_ts_format, which is different than the ts_format of the previously allocated QPs REAL_TIME_TS format (0x2). Thus, to resolve this, read the sq_ts_format, which also reflect the supported ts format for the QP when RoCE is disabled. Fixes: 4806f1e2fee8 ("net/mlx5: Set QP timestamp mode to default") Signed-off-by: Maher Sanalla Signed-off-by: Or Har-Toov Link: https://lore.kernel.org/r/32801966eb767c7fd62b8dea3b63991d5fbfe213.1718554199.git.leon@kernel.org Reviewed-by: Simon Horman Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a6366755586de861319c2dc317303df6bbc2f92d Author: Leon Romanovsky Date: Sun Jun 16 19:17:30 2024 +0300 RDMA/mlx4: Fix truncated output warning in alias_GUID.c [ Upstream commit 5953e0647cec703ef436ead37fed48943507b433 ] drivers/infiniband/hw/mlx4/alias_GUID.c: In function ‘mlx4_ib_init_alias_guid_service’: drivers/infiniband/hw/mlx4/alias_GUID.c:878:74: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 5 [-Werror=format-truncation=] 878 | snprintf(alias_wq_name, sizeof alias_wq_name, "alias_guid%d", i); | ^~ drivers/infiniband/hw/mlx4/alias_GUID.c:878:63: note: directive argument in the range [-2147483641, 2147483646] 878 | snprintf(alias_wq_name, sizeof alias_wq_name, "alias_guid%d", i); | ^~~~~~~~~~~~~~ drivers/infiniband/hw/mlx4/alias_GUID.c:878:17: note: ‘snprintf’ output between 12 and 22 bytes into a destination of size 15 878 | snprintf(alias_wq_name, sizeof alias_wq_name, "alias_guid%d", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Fixes: a0c64a17aba8 ("mlx4: Add alias_guid mechanism") Link: https://lore.kernel.org/r/1951c9500109ca7e36dcd523f8a5f2d0d2a608d1.1718554641.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 40ef9b895119f7c2aa0410e8a66f0192764c4a99 Author: Leon Romanovsky Date: Sun Jun 16 19:16:33 2024 +0300 RDMA/mlx4: Fix truncated output warning in mad.c [ Upstream commit 0d2e6992fc956e3308cd5376c18567def4cb3967 ] Increase size of the name array to avoid truncated output warning. drivers/infiniband/hw/mlx4/mad.c: In function ‘mlx4_ib_alloc_demux_ctx’: drivers/infiniband/hw/mlx4/mad.c:2197:47: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 4 [-Werror=format-truncation=] 2197 | snprintf(name, sizeof(name), "mlx4_ibt%d", port); | ^~ drivers/infiniband/hw/mlx4/mad.c:2197:38: note: directive argument in the range [-2147483645, 2147483647] 2197 | snprintf(name, sizeof(name), "mlx4_ibt%d", port); | ^~~~~~~~~~~~ drivers/infiniband/hw/mlx4/mad.c:2197:9: note: ‘snprintf’ output between 10 and 20 bytes into a destination of size 12 2197 | snprintf(name, sizeof(name), "mlx4_ibt%d", port); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/infiniband/hw/mlx4/mad.c:2205:48: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 2205 | snprintf(name, sizeof(name), "mlx4_ibwi%d", port); | ^~ drivers/infiniband/hw/mlx4/mad.c:2205:38: note: directive argument in the range [-2147483645, 2147483647] 2205 | snprintf(name, sizeof(name), "mlx4_ibwi%d", port); | ^~~~~~~~~~~~~ drivers/infiniband/hw/mlx4/mad.c:2205:9: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 12 2205 | snprintf(name, sizeof(name), "mlx4_ibwi%d", port); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/infiniband/hw/mlx4/mad.c:2213:48: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=] 2213 | snprintf(name, sizeof(name), "mlx4_ibud%d", port); | ^~ drivers/infiniband/hw/mlx4/mad.c:2213:38: note: directive argument in the range [-2147483645, 2147483647] 2213 | snprintf(name, sizeof(name), "mlx4_ibud%d", port); | ^~~~~~~~~~~~~ drivers/infiniband/hw/mlx4/mad.c:2213:9: note: ‘snprintf’ output between 11 and 21 bytes into a destination of size 12 2213 | snprintf(name, sizeof(name), "mlx4_ibud%d", port); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:244: drivers/infiniband/hw/mlx4/mad.o] Error 1 Fixes: fc06573dfaf8 ("IB/mlx4: Initialize SR-IOV IB support for slaves in master context") Link: https://lore.kernel.org/r/f3798b3ce9a410257d7e1ec7c9e285f1352e256a.1718554569.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9569c97b3c7ea8f75e02b18a167d2cadba24e2a3 Author: Andrei Lalaev Date: Mon Jun 17 20:30:18 2024 +0200 Input: qt1050 - handle CHIP_ID reading error [ Upstream commit 866a5c7e2781cf1b019072288f1f5c64186dcb63 ] If the device is missing, we get the following error: qt1050 3-0041: ID -1340767592 not supported Let's handle this situation and print more informative error when reading of CHIP_ID fails: qt1050 3-0041: Failed to read chip ID: -6 Fixes: cbebf5addec1 ("Input: qt1050 - add Microchip AT42QT1050 support") Signed-off-by: Andrei Lalaev Reviewed-by: Marco Felsch Link: https://lore.kernel.org/r/20240617183018.916234-1-andrey.lalaev@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit fa2eb7920e59027ce54e859cef1b72be6a23f2d4 Author: Konrad Dybcio Date: Tue Jun 18 16:42:18 2024 +0200 interconnect: qcom: qcm2290: Fix mas_snoc_bimc RPM master ID [ Upstream commit cd5ce4589081190281cc2537301edd4275fe55eb ] The value was wrong, resulting in misprogramming of the hardware. Fix it. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Reported-by: Stephan Gerhold Closes: https://lore.kernel.org/linux-arm-msm/ZgMs_xZVzWH5uK-v@gerhold.net/ Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240618-topic-2290_icc_2-v1-1-64446888a133@linaro.org Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit c916004860b651711fe990a1486a3dc1e0befdaa Author: Taniya Das Date: Wed Jun 12 16:38:26 2024 +0530 clk: qcom: gpucc-sa8775p: Update wait_val fields for GPU GDSC's [ Upstream commit 211681998d706d1e0fff6b62f89efcdf29c24978 ] Update wait_val fields as per the default hardware values of the GDSC as otherwise it would lead to GDSC FSM state stuck causing power on/off failures of the GSDC. Fixes: 0afa16afc36d ("clk: qcom: add the GPUCC driver for sa8775p") Signed-off-by: Taniya Das Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240612-sa8775p-v2-gcc-gpucc-fixes-v2-6-adcc756a23df@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6c0a1938183a44f1c164a4c55aff80a582bec7e9 Author: Taniya Das Date: Wed Jun 12 16:38:25 2024 +0530 clk: qcom: gpucc-sa8775p: Park RCG's clk source at XO during disable [ Upstream commit dff68b2f74547617dbb75d0d12f404877ec8f8ce ] The RCG's clk src has to be parked at XO while disabling as per the HW recommendation, hence use clk_rcg2_shared_ops to achieve the same. Also gpu_cc_cb_clk is recommended to be kept always ON, hence use clk_branch2_aon_ops to keep the clock always ON. Fixes: 0afa16afc36d ("clk: qcom: add the GPUCC driver for sa8775p") Signed-off-by: Taniya Das Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240612-sa8775p-v2-gcc-gpucc-fixes-v2-5-adcc756a23df@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f6896514c5edda63b28d12c466dd6662477f5560 Author: Taniya Das Date: Wed Jun 12 16:38:24 2024 +0530 clk: qcom: gpucc-sa8775p: Remove the CLK_IS_CRITICAL and ALWAYS_ON flags [ Upstream commit e69386d4a42afa5da6bfdcd4ac5ec61e1db04c61 ] The GPU clocks/GDSCs have been marked critical from the clock driver but the GPU driver votes on these resources as per the HW requirement. In the case where these clocks & GDSCs are left enabled, would have power impact and also cause GPU stability/corruptions. Fix the same by removing the CLK_IS_CRITICAL for clocks and ALWAYS_ON flags for the GPU GDSCs. Fixes: 0afa16afc36d ("clk: qcom: add the GPUCC driver for sa8775p") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20240612-sa8775p-v2-gcc-gpucc-fixes-v2-4-adcc756a23df@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0e3c462b1472b93f255d9a7be89198e208cb4116 Author: Taniya Das Date: Wed Jun 12 16:38:22 2024 +0530 clk: qcom: gcc-sa8775p: Update the GDSC wait_val fields and flags [ Upstream commit be208c0ccf7d861fc6109ca06c1a773512739af9 ] Update the GDSC wait_val fields as per the default hardware values as otherwise they would lead to GDSC FSM state to be stuck and causing failures to power on/off. Also add the GDSC flags as applicable and add support to control PCIE GDSC's using collapse vote registers. Fixes: 08c51ceb12f7 ("clk: qcom: add the GCC driver for sa8775p") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/20240612-sa8775p-v2-gcc-gpucc-fixes-v2-2-adcc756a23df@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6b8a9b71629ef2d073a8d515182fc6330f242cdb Author: Taniya Das Date: Fri Jun 21 17:34:23 2024 +0530 clk: qcom: gpucc-sm8350: Park RCG's clk source at XO during disable [ Upstream commit 313e2909023bef36ef7b6d1d9ff2d98febcaa28d ] The RCG's clk src has to be parked at XO while disabling as per the HW recommendation, hence use clk_rcg2_shared_ops to achieve the same. Fixes: 160758b05ab1 ("clk: qcom: add support for SM8350 GPUCC") Signed-off-by: Taniya Das Reviewed-by: Dmitry Baryshkov Tested-by: Dmitry Baryshkov # SM8350-HDK Link: https://lore.kernel.org/r/20240621-sm8350-gpucc-fixes-v1-1-22db60c7c5d3@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0fcc48494a1e3583c8d61150f9ef06f8dfd14a2d Author: Michael Walle Date: Fri Jun 21 14:09:29 2024 +0200 mtd: spi-nor: winbond: fix w25q128 regression [ Upstream commit d35df77707bf5ae1221b5ba1c8a88cf4fcdd4901 ] Commit 83e824a4a595 ("mtd: spi-nor: Correct flags for Winbond w25q128") removed the flags for non-SFDP devices. It was assumed that it wasn't in use anymore. This wasn't true. Add the no_sfdp_flags as well as the size again. We add the additional flags for dual and quad read because they have been reported to work properly by Hartmut using both older and newer versions of this flash, the similar flashes with 64Mbit and 256Mbit already have these flags and because it will (luckily) trigger our legacy SFDP parsing, so newer versions with SFDP support will still get the parameters from the SFDP tables. Reported-by: Hartmut Birr Closes: https://lore.kernel.org/r/CALxbwRo_-9CaJmt7r7ELgu+vOcgk=xZcGHobnKf=oT2=u4d4aA@mail.gmail.com/ Fixes: 83e824a4a595 ("mtd: spi-nor: Correct flags for Winbond w25q128") Reviewed-by: Linus Walleij Signed-off-by: Michael Walle Acked-by: Tudor Ambarus Reviewed-by: Esben Haabendal Reviewed-by: Pratyush Yadav Signed-off-by: Pratyush Yadav Link: https://lore.kernel.org/r/20240621120929.2670185-1-mwalle@kernel.org Signed-off-by: Sasha Levin commit 313231de3e76a7398f9cfb98fa227867c41e34f4 Author: Leon Romanovsky Date: Tue May 28 15:52:51 2024 +0300 RDMA/cache: Release GID table even if leak is detected [ Upstream commit a92fbeac7e94a420b55570c10fe1b90e64da4025 ] When the table is released, we nullify pointer to GID table, it means that in case GID entry leak is detected, we will leak table too. Delete code that prevents table destruction. Fixes: b150c3862d21 ("IB/core: Introduce GID entry reference counts") Link: https://lore.kernel.org/r/a62560af06ba82c88ef9194982bfa63d14768ff9.1716900410.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit fa6f16eff7320c91e908309e31be34cbbe4b7e58 Author: Hao Ge Date: Mon Jun 17 10:09:54 2024 +0800 ASoc: PCM6240: Return directly after a failed devm_kzalloc() in pcmdevice_i2c_probe() [ Upstream commit 3722873d49a1788d5420894d4f6f63e35f5c1f13 ] The value “-ENOMEM” was assigned to the local variable “ret” in one if branch after a devm_kzalloc() call failed at the beginning. This error code will trigger then a pcmdevice_remove() call with a passed null pointer so that an undesirable dereference will be performed. Thus return the appropriate error code directly. Fixes: 1324eafd37aa ("ASoc: PCM6240: Create PCM6240 Family driver code") Signed-off-by: Hao Ge Link: https://patch.msgid.link/20240617020954.17252-1-hao.ge@linux.dev Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e158d5ecd0c0676d13524275f8b7ff06f4468163 Author: Neil Armstrong Date: Thu Jun 6 15:11:14 2024 +0200 usb: typec-mux: nb7vpq904m: unregister typec switch on probe error and remove [ Upstream commit 74b64e760ee3433c0f8d95715038c869bcddacf7 ] Add the missing call to typec_switch_put() when probe fails and the nb7vpq904m_remove() call is called. Fixes: 348359e7c232 ("usb: typec: nb7vpq904m: Add an error handling path in nb7vpq904m_probe()") Signed-off-by: Neil Armstrong Fixes: 88d8f3ac9c67 ("usb: typec: add support for the nb7vpq904m Type-C Linear Redriver") Reviewed-by: Dmitry Baryshkov Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-2-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7c04f4334a91506c4aae4aea318a4a21bf1e7268 Author: Neil Armstrong Date: Thu Jun 6 15:11:13 2024 +0200 usb: typec-mux: ptn36502: unregister typec switch on probe error and remove [ Upstream commit 2be53b0436fda455e1bf6968ebae53f5d4f3cb0b ] Add the missing call to typec_switch_put() when probe fails and the ptn36502_remove() call is called. Fixes: 8e99dc783648 ("usb: typec: add support for PTN36502 redriver") Signed-off-by: Neil Armstrong Reviewed-by: Heikki Krogerus Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240606-topic-sm8x50-upstream-retimer-broadcast-mode-v2-1-c6f6eae479c3@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 90cda6c657f96f71e58bbc2ac26a40c870ff8901 Author: Simon Trimmer Date: Mon Jun 17 14:53:38 2024 +0100 ASoC: cs35l56: Accept values greater than 0 as IRQ numbers [ Upstream commit 3ec1428d7b7c519d757a013cef908d7e33dee882 ] IRQ lookup functions such as those in ACPI can return error values when an IRQ is not defined. The i2c core driver converts the error codes to a value of 0 and the SPI bus driver passes them unaltered to client device drivers. The cs35l56 driver should only accept positive non-zero values as IRQ numbers. Signed-off-by: Simon Trimmer Fixes: 8a731fd37f8b ("ASoC: cs35l56: Move utility functions to shared file") Link: https://msgid.link/r/20240617135338.82006-1-simont@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c9dcb01325ac5f0942e52ca6003a736563d4c78 Author: Shenghao Ding Date: Fri Jun 14 21:36:45 2024 +0800 ASoc: tas2781: Enable RCA-based playback without DSP firmware download [ Upstream commit 9f774c757e3fb2ac32dc4377e8f21f3364a8df81 ] In only loading RCA (Reconfigurable Architecture) binary case, no DSP program will be working inside tas2563/tas2781, that is dsp-bypass mode, do not support speaker protection, or audio acoustic algorithms in this mode. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding Reviewed-by: Pierre-Louis Bossart Link: https://msgid.link/r/20240614133646.910-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f7275af580b137f0d739e8d8466fd2e987b825f0 Author: Sourabh Jain Date: Fri May 10 15:52:35 2024 +0530 powerpc/kexec_file: fix cpus node update to FDT [ Upstream commit 932bed41217059638c78a75411b7893b121d2162 ] While updating the cpus node, commit 40c753993e3a ("powerpc/kexec_file: Use current CPU info while setting up FDT") first deletes all subnodes under the /cpus node. However, while adding sub-nodes back, it missed adding cpus subnodes whose device_type != "cpu", such as l2-cache*, l3-cache*, ibm,powerpc-cpu-features. Fix this by only deleting cpus sub-nodes of device_type == "cpus" and then adding all available nodes with device_type == "cpu". Fixes: 40c753993e3a ("powerpc/kexec_file: Use current CPU info while setting up FDT") Signed-off-by: Sourabh Jain Signed-off-by: Michael Ellerman Link: https://msgid.link/20240510102235.2269496-3-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit a1861bdd9f7da98ae83a9b26c59ce1953815fbb6 Author: Chiara Meiohas Date: Thu Jun 13 21:01:42 2024 +0300 RDMA/mlx5: Set mkeys for dmabuf at PAGE_SIZE [ Upstream commit a4e540119be565f47c305f295ed43f8e0bc3f5c3 ] Set the mkey for dmabuf at PAGE_SIZE to support any SGL after a move operation. ib_umem_find_best_pgsz returns 0 on error, so it is incorrect to check the returned page_size against PAGE_SIZE Fixes: 90da7dc8206a ("RDMA/mlx5: Support dma-buf based userspace memory region") Signed-off-by: Chiara Meiohas Reviewed-by: Michael Guralnik Link: https://lore.kernel.org/r/1e2289b9133e89f273a4e68d459057d032cbc2ce.1718301631.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ed67aa7da91732d6711d69c82b2f053ab0b5d5cc Author: James Clark Date: Wed May 29 14:36:26 2024 +0100 coresight: Fix ref leak when of_coresight_parse_endpoint() fails [ Upstream commit 7fcb9cb2fe47294e16067c3cfd25332c8662a115 ] of_graph_get_next_endpoint() releases the reference to the previous endpoint on each iteration, but when parsing fails the loop exits early meaning the last reference is never dropped. Fix it by dropping the refcount in the exit condition. Fixes: d375b356e687 ("coresight: Fix support for sparsely populated ports") Signed-off-by: James Clark Reported-by: Laurent Pinchart Reviewed-by: Laurent Pinchart Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20240529133626.90080-1-james.clark@arm.com Signed-off-by: Sasha Levin commit 7aa2a86bc9b53808a21be563c06f69ced470a1ca Author: Shivaprasad G Bhat Date: Wed Jun 5 13:06:28 2024 +0000 KVM: PPC: Book3S HV: Fix the get_one_reg of SDAR [ Upstream commit 009f6f42c67e9de737d6d3d199f92b21a8cb9622 ] The kvmppc_get_one_reg_hv() for SDAR is wrongly getting the SIAR instead of SDAR, possibly a paste error emanating from the previous refactoring. Patch fixes the wrong get_one_reg() for the same. Fixes: ebc88ea7a6ad ("KVM: PPC: Book3S HV: Use accessors for VCPU registers") Signed-off-by: Shivaprasad G Bhat Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://msgid.link/171759278410.1480.16404209606556979576.stgit@linux.ibm.com Signed-off-by: Sasha Levin commit d18ff82c2da9da29e033a1ed995f9f97b1f6fc5f Author: Shivaprasad G Bhat Date: Wed Jun 5 13:06:16 2024 +0000 KVM: PPC: Book3S HV: Fix the set_one_reg for MMCR3 [ Upstream commit f9ca6a10be20479d526f27316cc32cfd1785ed39 ] The kvmppc_set_one_reg_hv() wrongly get() the value instead of set() for MMCR3. Fix the same. Fixes: 5752fe0b811b ("KVM: PPC: Book3S HV: Save/restore new PMU registers") Signed-off-by: Shivaprasad G Bhat Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://msgid.link/171759276847.1480.16387950124201117847.stgit@linux.ibm.com Signed-off-by: Sasha Levin commit b9569896900481edf9d3eebef38a22935fa44dfb Author: Mostafa Saleh Date: Tue Jun 4 18:52:18 2024 +0000 iommu/arm-smmu-v3: Avoid uninitialized asid in case of error [ Upstream commit d3867e7148318e12b5d69b64950622f5ed06fe86 ] Static checker is complaining about the ASID possibly set uninitialized. This only happens in case of error and this value would be ignored anyway. A simple fix would be just to initialize the local variable to zero, this path will only be reached on the first attach to a domain where the CD is already initialized to zero. This avoids having to bloat the function with an error path. Closes: https://lore.kernel.org/linux-iommu/849e3d77-0a3c-43c4-878d-a0e061c8cd61@moroto.mountain/T/#u Reported-by: Dan Carpenter Signed-off-by: Mostafa Saleh Fixes: 04905c17f648 ("iommu/arm-smmu-v3: Build the whole CD in arm_smmu_make_s1_cd()") Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20240604185218.2602058-1-smostafa@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9d9029157d49feadab7f675fb645b1d35121d6c2 Author: Nuno Sa Date: Fri May 31 11:41:54 2024 +0200 iio: adc: adi-axi-adc: don't allow concurrent enable/disable calls [ Upstream commit 202b89f4b778d86a940f693785600acaccca6a2b ] Add proper mutex guards as we should not be able to disable the core in the middle of enabling it. Note there's no need to rush in backporting this as the only user of the backend does not do anything crazy.. Fixes: 794ef0e57854 ("iio: adc: adi-axi-adc: move to backend framework") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20240531-dev-axi-adc-drp-v3-1-e3fa79447c67@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 532248d0f0365150ba4d7563ff21695ce04398ad Author: Antoniu Miclaus Date: Thu May 30 12:28:34 2024 +0300 iio: frequency: adrf6780: rm clk provider include [ Upstream commit e2261b4a4de2804698935eb44f98dc897e1c44c3 ] The driver has no clock provider implementation, therefore remove the include. Fixes: 63aaf6d06d87 ("iio: frequency: adrf6780: add support for ADRF6780") Signed-off-by: Antoniu Miclaus Link: https://lore.kernel.org/r/20240530092835.36892-1-antoniu.miclaus@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1ff0fc4949e22425eead126eeb1f067b20c9ca04 Author: Nuno Sa Date: Wed May 22 14:54:05 2024 +0200 iio: adc: ad9467: use DMA safe buffer for spi [ Upstream commit 7a8e7f13f99b31c85b77b362cb7b7a23fead11d3 ] Make sure we use a DMA safe buffer (IIO_DMA_MINALIGN) for all the spi transfers. Only relevant for writes since for reads spi_write_then_read() is used which does not require DMA safe buffers. Also note that for consistency, ad9467_spi_read() is also taking struct ad9467_state as a parameter (even if not really needed). Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20240522-dev-ad9467-dma-v2-1-a37bec463632@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0019bd1e6c3485910de45a8f9da1fa5f7006d4d8 Author: Xianwei Zhao Date: Thu May 16 15:16:12 2024 +0800 clk: meson: s4: fix pwm_j_div parent clock [ Upstream commit c591745831e75b11ef19fb33c5c5a16e4d3f7fbf ] Update peripherals pwm_j_div's parent clock to pwm_j_mux Fixes: 57b55c76aaf1 ("clk: meson: S4: add support for Amlogic S4 SoC peripheral clock controller") Signed-off-by: Xianwei Zhao Link: https://lore.kernel.org/r/20240516071612.2978201-1-xianwei.zhao@amlogic.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit b156f8f48258017fb32901096b18746a7a06503d Author: Xianwei Zhao Date: Mon Jun 3 18:04:33 2024 +0800 clk: meson: s4: fix fixed_pll_dco clock [ Upstream commit c1380adf2e8680a00dedaf1b25c19beadbbe5bbd ] The fixed_pll_dco output frequency is not accurate, add frac factor for fixed_pll_dco clk to fix it. Fixes: 57b55c76aaf1 ("clk: meson: S4: add support for Amlogic S4 SoC peripheral clock controller") Signed-off-by: Xianwei Zhao Link: https://lore.kernel.org/r/20240603-s4_fixedpll-v1-1-2b2a98630841@amlogic.com Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin commit 69b5557d750ae08f04d5e7bee01fc3bc8f959511 Author: Taniya Das Date: Fri May 31 15:21:42 2024 +0530 clk: qcom: camcc-sc7280: Add parent dependency to all camera GDSCs [ Upstream commit 63aec3e4d987fd43237f557460345bca3b51e530 ] Camera titan top GDSC is a parent supply to all other camera GDSCs. Titan top GDSC is required to be enabled before enabling any other camera GDSCs and it should be disabled only after all other camera GDSCs are disabled. Ensure this behavior by marking titan top GDSC as parent of all other camera GDSCs. Fixes: 1daec8cfebc2 ("clk: qcom: camcc: Add camera clock controller driver for SC7280") Signed-off-by: Taniya Das Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240531095142.9688-4-quic_tdas@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5f25486c4ee7215cc24323182b866586397a939a Author: Taniya Das Date: Fri May 31 15:21:41 2024 +0530 clk: qcom: gcc-sc7280: Update force mem core bit for UFS ICE clock [ Upstream commit f38467b5a920be1473710428a93c4e54b6f8a0c1 ] Update the force mem core bit for UFS ICE clock to force the core on signal to remain active during halt state of the clk. When retention bit of the clock is set the memories of the subsystem will retain the logic across power states. Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280") Signed-off-by: Taniya Das Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240531095142.9688-3-quic_tdas@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f94068f2343eeda61461ff08e47676bdb334d5d3 Author: Lothar Rubusch Date: Sun May 26 10:31:28 2024 +0000 crypto: atmel-sha204a - fix negated return value [ Upstream commit aabbf2135f9a9526991f17cb0c78cf1ec878f1c2 ] Fix negated variable return value. Fixes: e05ce444e9e5 ("crypto: atmel-sha204a - add reading from otp zone") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-crypto/34cd4179-090e-479d-b459-8d0d35dd327d@moroto.mountain/ Signed-off-by: Lothar Rubusch Reviewed-by: Dan Carpenter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1041f828492891fcb7021aa79a0aee4de0dd1037 Author: Christophe JAILLET Date: Sat May 25 17:14:35 2024 +0200 crypto: tegra - Remove an incorrect iommu_fwspec_free() call in tegra_se_remove() [ Upstream commit 8d7c52cb4184d3dc26dde62b4f5acd48de0768ae ] The only iommu function call in this driver is a tegra_dev_iommu_get_stream_id() which does not allocate anything and does not take any reference. So there is no point in calling iommu_fwspec_free() in the remove function. Remove this incorrect function call. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Christophe JAILLET Tested-by: Akhil R Acked-by: Akhil R Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e42cc7d832b43695bbcd09b6582b26b542f5f86a Author: Minwoo Im Date: Mon May 20 07:14:56 2024 +0900 scsi: ufs: mcq: Fix missing argument 'hba' in MCQ_OPR_OFFSET_n [ Upstream commit 2fc39848952dfb91a9233563cc1444669b8e79c3 ] The MCQ_OPR_OFFSET_n macro takes 'hba' in the caller context without receiving 'hba' instance as an argument. To prevent potential bugs in future use cases, add an argument 'hba'. Fixes: 2468da61ea09 ("scsi: ufs: core: mcq: Configure operation and runtime interface") Cc: Asutosh Das Signed-off-by: Minwoo Im Link: https://lore.kernel.org/r/20240519221457.772346-2-minwoo.im@samsung.com Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1911fd52a37a294f08457892aea001f7c811c8de Author: Andy Chiu Date: Fri May 10 00:26:52 2024 +0800 riscv: smp: fail booting up smp if inconsistent vlen is detected [ Upstream commit 38a94c46660f5612c6ef37ec9754ec1543b038cd ] Currently we only support Vector for SMP platforms, that is, all SMP cores have the same vlenb. If we happen to detect a mismatching vlen, it is better to just fail bootting it up to prevent further race/scheduling issues. Also, move .Lsecondary_park forward and chage `tail smp_callin` into a regular call in the early assembly. So a core would be parked right after a return from smp_callin. Note that a successful smp_callin does not return. Fixes: 7017858eb2d7 ("riscv: Introduce riscv_v_vsize to record size of Vector context") Reported-by: Conor Dooley Closes: https://lore.kernel.org/linux-riscv/20240228-vicinity-cornstalk-4b8eb5fe5730@spud/ Signed-off-by: Andy Chiu Reviewed-by: Conor Dooley Reviewed-by: Yunhui Cui Link: https://lore.kernel.org/r/20240510-zve-detection-v5-2-0711bdd26c12@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit b2808d2370cc27cfbf8ca07072dc7c1e172f25c6 Author: Jon Hunter Date: Wed May 8 10:22:07 2024 +0100 PCI: tegra194: Set EP alignment restriction for inbound ATU [ Upstream commit d19a86d584e04191cdab7ced24d7ed791075697a ] Tegra194 and Tegra234 PCIe EP controllers have 64K alignment restriction for the inbound ATU. Set the endpoint inbound ATU alignment to 64kB in the Tegra194 PCIe driver. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Suggested-by: Manikanta Maddireddy Link: https://lore.kernel.org/linux-pci/20240508092207.337063-1-jonathanh@nvidia.com Signed-off-by: Jon Hunter Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit 3ff3bdde950f1840df4030726cef156758a244d7 Author: Marek Vasut Date: Sun May 12 01:54:50 2024 +0200 PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup() [ Upstream commit c93637e6a4c4e1d0e85ef7efac78d066bbb24d96 ] Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources. This makes an actual link issue less verbose. First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller. In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pm_test, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcar_pcie_wakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PM_ENTER_L1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit. Once rcar_pcie_wakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state. Reduce this warning verbosity. In case the link is really broken, the rcar_pcie_config_access() would fail, otherwise it will succeed and any system with this controller and ASM1062 can suspend without generating a backtrace. Fixes: 84b576146294 ("PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access()") Link: https://lore.kernel.org/linux-pci/20240511235513.77301-1-marek.vasut+renesas@mailbox.org Signed-off-by: Marek Vasut Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit dbcdd1863ba2ec9b76ec131df25d797709e05597 Author: Aleksandr Mishin Date: Sun May 5 09:15:17 2024 +0300 PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs() [ Upstream commit a231707a91f323af1e5d9f1722055ec2fc1c7775 ] If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning. This will cause a NULL pointer dereference. Fix this bug by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources") Link: https://lore.kernel.org/linux-pci/20240505061517.11527-1-amishin@t-argos.ru Suggested-by: Bjorn Helgaas Suggested-by: Manivannan Sadhasivam Signed-off-by: Aleksandr Mishin Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit 36aaa68b1a99128726d231345867578865211f20 Author: Siddharth Vadapalli Date: Thu Mar 28 14:20:41 2024 +0530 PCI: keystone: Don't enable BAR 0 for AM654x [ Upstream commit 9ffa0e70b2daf9b0271e4960b7c8a2350e2cda08 ] After 6ab15b5e7057 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus"), ks_pcie_v3_65_add_bus() enabled BAR 0 for both v3.65a and v4.90a devices. On the AM654x SoC, which uses v4.90a, enabling BAR 0 causes Completion Timeouts when setting up MSI-X. These timeouts delay boot of the AM654x by about 45 seconds. Move the BAR 0 initialization to ks_pcie_msi_host_init(), which is only used for v3.65a devices, and remove ks_pcie_v3_65_add_bus(). [bhelgaas: commit log] Fixes: 6ab15b5e7057 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus") Link: https://lore.kernel.org/linux-pci/20240328085041.2916899-3-s-vadapalli@ti.com Suggested-by: Bjorn Helgaas Suggested-by: Niklas Cassel Suggested-by: Serge Semin Signed-off-by: Siddharth Vadapalli Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit 09904aba0cf8e6f947277f2c1816d416bc750f66 Author: Siddharth Vadapalli Date: Thu Mar 28 14:20:40 2024 +0530 PCI: keystone: Relocate ks_pcie_set/clear_dbi_mode() [ Upstream commit 5125fdc3292eea20870d4e6cefa62dc1245ce7ec ] Relocate ks_pcie_set_dbi_mode() and ks_pcie_clear_dbi_mode() to avoid forward declaration in a subsequent patch. No functional change intended. Link: https://lore.kernel.org/linux-pci/20240328085041.2916899-2-s-vadapalli@ti.com Signed-off-by: Siddharth Vadapalli Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Stable-dep-of: 9ffa0e70b2da ("PCI: keystone: Don't enable BAR 0 for AM654x") Signed-off-by: Sasha Levin commit ffffd95e46be023b9710f047ce6e624febe711de Author: Ilpo Järvinen Date: Tue May 7 13:25:16 2024 +0300 PCI: Fix resource double counting on remove & rescan [ Upstream commit 903534fa7d30214d8ba840ab1cd9e917e0c88e41 ] pbus_size_mem() keeps the size of the optional resources in children_add_size. When calculating the PCI bridge window size, calculate_memsize() lower bounds size by old_size before adding children_add_size and performing the window size alignment. This results in double counting for the resources in children_add_size because old_size may be based on the previous size of the bridge window after it has already included children_add_size (that is, size1 in pbus_size_mem() from an earlier invocation of that function). As a result, on repeated remove of the bus & rescan cycles the resource size keeps increasing when children_add_size is non-zero as can be seen from this extract: iomem0: 23fffd00000-23fffdfffff : PCI Bus 0000:03 # 1MiB iomem1: 20000000000-200001fffff : PCI Bus 0000:03 # 2MiB iomem2: 20000000000-200002fffff : PCI Bus 0000:03 # 3MiB iomem3: 20000000000-200003fffff : PCI Bus 0000:03 # 4MiB iomem4: 20000000000-200004fffff : PCI Bus 0000:03 # 5MiB Solve the double counting by moving old_size check later in calculate_memsize() so that children_add_size is already accounted for. After the patch, the bridge window retains its size as expected: iomem0: 23fffd00000-23fffdfffff : PCI Bus 0000:03 # 1MiB iomem1: 20000000000-200000fffff : PCI Bus 0000:03 # 1MiB iomem2: 20000000000-200000fffff : PCI Bus 0000:03 # 1MiB Fixes: a4ac9fea016f ("PCI : Calculate right add_size") Link: https://lore.kernel.org/r/20240507102523.57320-2-ilpo.jarvinen@linux.intel.com Tested-by: Lidong Wang Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit af4ad016abb1632ff7ee598a6037952b495e5b80 Author: Manivannan Sadhasivam Date: Thu Apr 18 13:29:58 2024 +0530 PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init() [ Upstream commit 5a5095a8bd1bd349cce1c879e5e44407a34dda8a ] Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference. Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747) Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables. [kwilczynski: commit log] Fixes: 5e50ee27d4a5 ("PCI: pci-epf-test: Add support to defer core initialization") Closes: https://lore.kernel.org/linux-pci/024b5826-7180-4076-ae08-57d2584cca3f@moroto.mountain Link: https://lore.kernel.org/linux-pci/20240418-pci-epf-test-fix-v2-1-eacd54831444@linaro.org Reported-by: Dan Carpenter Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit b5046de32fd1532c3f67065197fc1da82f0b5193 Author: Chenyuan Yang Date: Tue Apr 30 15:44:53 2024 +0300 iio: Fix the sorting functionality in iio_gts_build_avail_time_table [ Upstream commit 5acc3f971a01be48d5ff4252d8f9cdb87998cdfb ] The sorting in iio_gts_build_avail_time_table is not working as intended. It could result in an out-of-bounds access when the time is zero. Here are more details: 1. When the gts->itime_table[i].time_us is zero, e.g., the time sequence is `3, 0, 1`, the inner for-loop will not terminate and do out-of-bound writes. This is because once `times[j] > new`, the value `new` will be added in the current position and the `times[j]` will be moved to `j+1` position, which makes the if-condition always hold. Meanwhile, idx will be added one, making the loop keep running without termination and out-of-bound write. 2. If none of the gts->itime_table[i].time_us is zero, the elements will just be copied without being sorted as described in the comment "Sort times from all tables to one and remove duplicates". For more details, please refer to https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com. Reported-by: Chenyuan Yang Suggested-by: Matti Vaittinen Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers") Signed-off-by: Chenyuan Yang Co-developed-by: Matti Vaittinen Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/d501ade8c1f7b202d34c6404eda423489cab1df5.1714480171.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5532e0c56365959bcc220d43f639286accb38572 Author: Benjamin Coddington Date: Thu Jul 11 13:21:00 2024 -0400 SUNRPC: Fixup gss_status tracepoint error output [ Upstream commit b9fae9f06d84ffab0f3f9118f3a96bbcdc528bf6 ] The GSS routine errors are values, not flags. Fixes: 0c77668ddb4e ("SUNRPC: Introduce trace points in rpc_auth_gss.ko") Signed-off-by: Benjamin Coddington Reviewed-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 387e6e9d110250946df4d4ebef9c2def5c7a4722 Author: Christoph Hellwig Date: Thu Jul 11 09:17:02 2024 +0200 nfs: pass explicit offset/count to trace events [ Upstream commit fada32ed6dbc748f447c8d050a961b75d946055a ] nfs_folio_length is unsafe to use without having the folio locked and a check for a NULL ->f_mapping that protects against truncations and can lead to kernel crashes. E.g. when running xfstests generic/065 with all nfs trace points enabled. Follow the model of the XFS trace points and pass in an explіcit offset and length. This has the additional benefit that these values can be more accurate as some of the users touch partial folio ranges. Fixes: eb5654b3b89d ("NFS: Enable tracing of nfs_invalidate_folio() and nfs_launder_folio()") Reported-by: Chuck Lever Signed-off-by: Christoph Hellwig Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b69c02dea9bfd39998087c78383bb672d2fc62a1 Author: Luke D. Jones Date: Tue Jul 16 13:11:30 2024 +1200 platform/x86: asus-wmi: fix TUF laptop RGB variant [ Upstream commit d8b17a364ec48239fccb65efe74bb485e79e6743 ] In kbd_rgb_mode_store the dev_get_drvdata() call was assuming the device data was asus_wmi when it was actually led_classdev. This patch corrects this by making the correct chain of calls to get the asus_wmi driver data. Fixes: ae834a549ec1 ("platform/x86: asus-wmi: add support variant of TUF RGB") Tested-by: Denis Benato Signed-off-by: Luke D. Jones Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20240716011130.17464-2-luke@ljones.dev Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 872539936742609578045a0d542e73b3cf2da8a1 Author: Ian Rogers Date: Wed Jul 3 18:17:45 2024 -0700 perf dso: Fix address sanitizer build [ Upstream commit 1553419c3c10cf386496e68b90b5d0ce966ac614 ] Various files had been missed from having accessor functions added for the sake of dso reference count checking. Add the function calls and missing dso accessor functions. Fixes: ee756ef7491e ("perf dso: Add reference count checking and accessor functions") Signed-off-by: Ian Rogers Cc: James Clark Cc: Suzuki K Poulose Cc: Yunseong Kim Cc: Will Deacon Cc: Mike Leach Cc: Leo Yan Cc: Athira Rajeev Cc: John Garry Link: https://lore.kernel.org/r/20240704011745.1021288-1-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 54765806773eff0119222d635f797974494d82be Author: Andreas Larsson Date: Wed Jul 10 11:41:53 2024 +0200 sparc64: Fix incorrect function signature and add prototype for prom_cif_init [ Upstream commit a6c3ea1ec96307dbfbb2f16d96c674c5cc80f445 ] Remove the unused cif_stack argument and add a protype in oplib_64.h Commit ef3e035c3a9b ("sparc64: Fix register corruption in top-most kernel stack frame during boot.") removed the cif_stack argument to prom_cif init in the declaration at the caller site and the usage of it within prom_cif_init, but not in the function signature of the function itself. This also fixes the following warning: arch/sparc/prom/p1275.c:52:6: warning: no previous prototype for ‘prom_cif_init’ Fixes: ef3e035c3a9b ("sparc64: Fix register corruption in top-most kernel stack frame during boot.") Link: https://lore.kernel.org/r/20240710094155.458731-3-andreas@gaisler.com Signed-off-by: Andreas Larsson Signed-off-by: Sasha Levin commit 2c370dda0ee7198121b2399fe7e887eed0a4eb25 Author: Dan Carpenter Date: Thu Jul 4 10:19:32 2024 -0500 leds: flash: leds-qcom-flash: Test the correct variable in init [ Upstream commit 87e552ad654554be73e62dd43c923bcee215287d ] This code was passing the incorrect pointer to PTR_ERR_OR_ZERO() so it always returned success. It should have been checking the array element instead of the array itself. Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/ZoWJS_epjIMCYITg@stanley.mountain Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit c9c1d9be6f22f90a7bf3bc3a9357fe54bf4c88f6 Author: Thomas Zimmermann Date: Mon Jul 8 16:21:37 2024 +0200 drm/qxl: Pin buffer objects for internal mappings [ Upstream commit c537fb4e3d36e7cd1a0837dd577cd30d3d64f1bc ] Add qxl_bo_pin_and_vmap() that pins and vmaps a buffer object in one step. Update callers of the regular qxl_bo_vmap(). Fixes a bug where qxl accesses an unpinned buffer object while it is being moved; such as with the monitor-description BO. An typical error is shown below. [ 4.303586] [drm:drm_atomic_helper_commit_planes] *ERROR* head 1 wrong: 65376256x16777216+0+0 [ 4.586883] [drm:drm_atomic_helper_commit_planes] *ERROR* head 1 wrong: 65376256x16777216+0+0 [ 4.904036] [drm:drm_atomic_helper_commit_planes] *ERROR* head 1 wrong: 65335296x16777216+0+0 [ 5.374347] [drm:qxl_release_from_id_locked] *ERROR* failed to find id in release_idr Commit b33651a5c98d ("drm/qxl: Do not pin buffer objects for vmap") removed the implicit pin operation from qxl's vmap code. This is the correct behavior for GEM and PRIME interfaces, but the pin is still needed for qxl internal operation. Also add a corresponding function qxl_bo_vunmap_and_unpin() and remove the old qxl_bo_vmap() helpers. Future directions: BOs should not be pinned or vmapped unnecessarily. The pin-and-vmap operation should be removed from the driver and a temporary mapping should be established with a vmap_local-like helper. See the client helper drm_client_buffer_vmap_local() for semantics. v2: - unreserve BO on errors in qxl_bo_pin_and_vmap() (Dmitry) Signed-off-by: Thomas Zimmermann Fixes: b33651a5c98d ("drm/qxl: Do not pin buffer objects for vmap") Reported-by: David Kaplan Closes: https://lore.kernel.org/dri-devel/ab0fb17d-0f96-4ee6-8b21-65d02bb02655@suse.de/ Tested-by: David Kaplan Reviewed-by: Daniel Vetter Cc: Thomas Zimmermann Cc: Dmitry Osipenko Cc: Christian König Cc: Zack Rusin Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux.dev Cc: spice-devel@lists.freedesktop.org Reviewed-by: Dmitry Osipenko Reviewed-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20240708142208.194361-1-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 024d8556f37fccb4686f7733952390d6566c2ecc Author: Jan Kara Date: Thu Jun 13 17:02:34 2024 +0200 ext4: avoid writing unitialized memory to disk in EA inodes [ Upstream commit 65121eff3e4c8c90f8126debf3c369228691c591 ] If the extended attribute size is not a multiple of block size, the last block in the EA inode will have uninitialized tail which will get written to disk. We will never expose the data to userspace but still this is not a good practice so just zero out the tail of the block as it isn't going to cause a noticeable performance overhead. Fixes: e50e5129f384 ("ext4: xattr-in-inode support") Reported-by: syzbot+9c1fe13fcb51574b249b@syzkaller.appspotmail.com Reported-by: Hugh Dickins Signed-off-by: Jan Kara Link: https://patch.msgid.link/20240613150234.25176-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 149a0691bf95e4c2b555ab45987cbbc4c34ef21a Author: Luis Henriques (SUSE) Date: Tue Jun 18 15:43:12 2024 +0100 ext4: don't track ranges in fast_commit if inode has inlined data [ Upstream commit 7882b0187bbeb647967a7b5998ce4ad26ef68a9a ] When fast-commit needs to track ranges, it has to handle inodes that have inlined data in a different way because ext4_fc_write_inode_data(), in the actual commit path, will attempt to map the required blocks for the range. However, inodes that have inlined data will have it's data stored in inode->i_block and, eventually, in the extended attribute space. Unfortunately, because fast commit doesn't currently support extended attributes, the solution is to mark this commit as ineligible. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039883 Signed-off-by: Luis Henriques (SUSE) Tested-by: Ben Hutchings Fixes: 9725958bb75c ("ext4: fast commit may miss tracking unwritten range during ftruncate") Link: https://patch.msgid.link/20240618144312.17786-1-luis.henriques@linux.dev Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4ebf5bfd3400143c9277db1c96bdcbb6b9465912 Author: Olga Kornievskaia Date: Mon Jun 24 09:28:27 2024 -0400 NFSv4.1 another fix for EXCHGID4_FLAG_USE_PNFS_DS for DS server [ Upstream commit 4840c00003a2275668a13b82c9f5b1aed80183aa ] Previously in order to mark the communication with the DS server, we tried to use NFS_CS_DS in cl_flags. However, this flag would only be saved for the DS server and in case where DS equals MDS, the client would not find a matching nfs_client in nfs_match_client that represents the MDS (but is also a DS). Instead, don't rely on the NFS_CS_DS but instead use NFS_CS_PNFS. Fixes: 379e4adfddd6 ("NFSv4.1: fixup use EXCHGID4_FLAG_USE_PNFS_DS for DS server") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 030fdc351225cc427455a99dd24874c28474d595 Author: NeilBrown Date: Wed Jun 19 11:05:13 2024 +1000 SUNRPC: avoid soft lockup when transmitting UDP to reachable server. [ Upstream commit 6258cf25d5e3155c3219ab5a79b970eef7996356 ] Prior to the commit identified below, call_transmit_status() would handle -EPERM and other errors related to an unreachable server by falling through to call_status() which added a 3-second delay and handled the failure as a timeout. Since that commit, call_transmit_status() falls through to handle_bind(). For UDP this moves straight on to handle_connect() and handle_transmit() so we immediately retransmit - and likely get the same error. This results in an indefinite loop in __rpc_execute() which triggers a soft-lockup warning. For the errors that indicate an unreachable server, call_transmit_status() should fall back to call_status() as it did before. This cannot cause the thundering herd that the previous patch was avoiding, as the call_status() will insert a delay. Fixes: ed7dc973bd91 ("SUNRPC: Prevent thundering herd when the socket is not connected") Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit fb778472ba46685581b176e24acd49067edd31b6 Author: Chuck Lever Date: Tue Jun 4 15:45:23 2024 -0400 xprtrdma: Fix rpcrdma_reqs_reset() [ Upstream commit acd9f2dd23c632568156217aac7a05f5a0313152 ] Avoid FastReg operations getting MW_BIND_ERR after a reconnect. rpcrdma_reqs_reset() is called on transport tear-down to get each rpcrdma_req back into a clean state. MRs on req->rl_registered are waiting for a FastReg, are already registered, or are waiting for invalidation. If the transport is being torn down when reqs_reset() is called, the matching LocalInv might never be posted. That leaves these MR registered /and/ on req->rl_free_mrs, where they can be re-used for the next connection. Since xprtrdma does not keep specific track of the MR state, it's not possible to know what state these MRs are in, so the only safe thing to do is release them immediately. Fixes: 5de55ce951a1 ("xprtrdma: Release in-flight MRs on disconnect") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit fecdddd8524d6817de66da7def22d4917e071480 Author: Javier Carrasco Date: Wed Jun 26 21:37:03 2024 +0200 mfd: omap-usb-tll: Use struct_size to allocate tll [ Upstream commit 40176714c818b0b6a2ca8213cdb7654fbd49b742 ] Commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") changed the memory allocation of 'tll' to consolidate it into a single allocation, introducing an incorrect size calculation. In particular, the allocation for the array of pointers was converted into a single-pointer allocation. The memory allocation used to occur in two steps: tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL); tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk *) * tll->nch, GFP_KERNEL); And it turned that into the following allocation: tll = devm_kzalloc(dev, sizeof(*tll) + sizeof(tll->ch_clk[nch]), GFP_KERNEL); sizeof(tll->ch_clk[nch]) returns the size of a single pointer instead of the expected nch pointers. This bug went unnoticed because the allocation size was small enough to fit within the minimum size of a memory allocation for this particular case [1]. The complete allocation can still be done at once with the struct_size macro, which comes in handy for structures with a trailing flexible array. Fix the memory allocation to obtain the original size again. Link: https://lore.kernel.org/all/202406261121.2FFD65647@keescook/ [1] Fixes: 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Reviewed-by: Kees Cook Signed-off-by: Javier Carrasco Fixes: commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Link: https://lore.kernel.org/r/20240626-omap-usb-tll-counted_by-v2-1-4bedf20d1b51@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit abf9d5c35453a46de3c8309660134ec9756b3000 Author: Arnd Bergmann Date: Wed May 29 11:48:47 2024 +0200 mfd: rsmu: Split core code into separate module [ Upstream commit c879a8c39dd55e7fabdd8d13341f7bc5200db377 ] Linking a file into two modules can have unintended side-effects and produces a W=1 warning: scripts/Makefile.build:236: drivers/mfd/Makefile: rsmu_core.o is added to multiple modules: rsmu-i2c rsmu-spi Make this one a separate module instead. Fixes: a1867f85e06e ("mfd: Add Renesas Synchronization Management Unit (SMU) support") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240529094856.1869543-1-arnd@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 35f45d148d0414322e4eb07e2a1bbc9ced07f8fe Author: Steven Price Date: Wed Jul 3 16:56:46 2024 +0100 drm/panthor: Record devfreq busy as soon as a job is started [ Upstream commit 896868eded124059023be0af92d68cdaf9b4de70 ] If a queue is already assigned to the hardware, then a newly submitted job can start straight away without waiting for the tick. However in this case the devfreq infrastructure isn't notified that the GPU is busy. By the time the tick happens the job might well have finished and no time will be accounted for the GPU being busy. Fix this by recording the GPU as busy directly in queue_run_job() in the case where there is a CSG assigned and therefore we just ring the doorbell. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Signed-off-by: Steven Price Reviewed-by: Boris Brezillon Reviewed-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20240703155646.80928-1-steven.price@arm.com Signed-off-by: Sasha Levin commit 8b833796fa231a1fcb7780fe667eea2581ac987b Author: Adrian Hunter Date: Tue Jun 25 13:45:32 2024 +0300 perf intel-pt: Fix exclude_guest setting [ Upstream commit b40934ae32232140e85dc7dc1c3ea0e296986723 ] In the past, the exclude_guest setting has had no effect on Intel PT tracing, but that may not be the case in the future. Set the flag correctly based upon whether KVM is using Intel PT "Host/Guest" mode, which is determined by the kvm_intel module parameter pt_mode: pt_mode=0 System-wide mode : host and guest output to host buffer pt_mode=1 Host/Guest mode : host/guest output to host/guest buffers respectively Fixes: 6e86bfdc4a60 ("perf intel-pt: Support decoding of guest kernel") Signed-off-by: Adrian Hunter Link: https://lore.kernel.org/r/20240625104532.11990-3-adrian.hunter@intel.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit f44c448bfb2a700fc4dc641315927f8dc83f87ab Author: Adrian Hunter Date: Tue Jun 25 13:45:31 2024 +0300 perf intel-pt: Fix aux_watermark calculation for 64-bit size [ Upstream commit 36b4cd990a8fd3f5b748883050e9d8c69fe6398d ] aux_watermark is a u32. For a 64-bit size, cap the aux_watermark calculation at UINT_MAX instead of truncating it to 32-bits. Fixes: 874fc35cdd55 ("perf intel-pt: Use aux_watermark") Signed-off-by: Adrian Hunter Link: https://lore.kernel.org/r/20240625104532.11990-2-adrian.hunter@intel.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit b7182f73d7568d186d60e1e06bf68b4888c22a14 Author: Dikshita Agarwal Date: Wed Jan 10 11:42:14 2024 +0530 media: venus: flush all buffers in output plane streamoff [ Upstream commit e750a4b1224142bd8dd057b0d5adf8a5608b7e77 ] For scenarios, when source change is followed by VIDIOC_STREAMOFF on output plane, driver should discard any queued OUTPUT buffers, which are not decoded or dequeued. Flush with HFI_FLUSH_INPUT does not have any actual impact. So, fix it, by invoking HFI_FLUSH_ALL, which will flush all queued buffers. Fixes: 85872f861d4c ("media: venus: Mark last capture buffer") Signed-off-by: Dikshita Agarwal Tested-by: Nathan Hebert Reviewed-by: Bryan O'Donoghue Signed-off-by: Stanimir Varbanov Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5b9eb7e0ab828231881ffa4fbba2342f108932d3 Author: Namhyung Kim Date: Thu Jun 27 17:06:03 2024 -0700 perf stat: Fix a segfault with --per-cluster --metric-only [ Upstream commit caa463bb79a82ac5fce05a0dcf7893d94c84fc5e ] The new --per-cluster option was added recently but it forgot to update the aggr_header fields which are used for --metric-only option. And it resulted in a segfault due to NULL string in fputs(). Fixes: cbc917a1b03b ("perf stat: Support per-cluster aggregation") Reviewed-by: Yicong Yang Tested-by: Yicong Yang Tested-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20240628000604.1296808-1-namhyung@kernel.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit c5d98f78ef3aed91cba08bb41f4dd12c34c67b08 Author: Michael Walle Date: Tue Jun 4 10:33:37 2024 +0200 drm/mediatek/dp: Fix spurious kfree() [ Upstream commit 8ad49a92cff4bab13eb2f2725243f5f31eff3f3b ] drm_edid_to_sad() might return an error or just zero. If that is the case, we must not free the SADs because there was no allocation in the first place. Fixes: dab12fa8d2bd ("drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection") Signed-off-by: Michael Walle Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Jani Nikula Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20240604083337.1879188-1-mwalle@kernel.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 7d44a63b4860a0a2ae64ab1a075b92f92437ba30 Author: Michael Walle Date: Thu Jun 6 11:21:22 2024 +0200 drm/mediatek: dpi/dsi: Fix possible_crtcs calculation [ Upstream commit 9ff6df49e6cbcc9834865870d7c4f3059b0891d3 ] mtk_find_possible_crtcs() assumes that the main path will always have the CRTC with id 0, the ext id 1 and the third id 2. This is only true if the paths are all available. But paths are optional (see also comment in mtk_drm_kms_init()), e.g. the main path might not be enabled or available at all. Then the CRTC IDs will shift one up, e.g. ext will be 0 and the third path will be 1. To fix that, dynamically calculate the IDs by the presence of the paths. While at it, make the return code a signed one and return -ENODEV if no path is found and handle the error in the callers. Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc way") Suggested-by: Nícolas F. R. A. Prado Signed-off-by: Michael Walle Link: https://patchwork.kernel.org/project/dri-devel/patch/20240606092122.2026313-1-mwalle@kernel.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 081ff4c0ef1884ae55f7adb8944efd22e22d8724 Author: Ma Ke Date: Wed Jun 26 21:06:50 2024 +0800 drm/amd/display: Add null check before access structs [ Upstream commit c96140000915b610d86f941450e15ca552de154a ] In enable_phantom_plane, we should better check null pointer before accessing various structs. Fixes: 09a4ec5da92c ("drm/amd/display: Refactor dc_state interface") Signed-off-by: Ma Ke Reviewed-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 81f819c537d29932e4b9267f02411cbc8b355178 Author: Luis Henriques (SUSE) Date: Wed May 15 09:28:57 2024 +0100 ext4: fix infinite loop when replaying fast_commit [ Upstream commit 907c3fe532253a6ef4eb9c4d67efb71fab58c706 ] When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem! Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Luis Henriques (SUSE) Reviewed-by: Zhang Yi Link: https://patch.msgid.link/20240515082857.32730-1-luis.henriques@linux.dev Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b8e7d26610fffc5fcaaaae6d98131234dcb57ed4 Author: Hsiao Chien Sung Date: Fri Jun 14 11:49:37 2024 +0800 drm/mediatek: Remove less-than-zero comparison of an unsigned value [ Upstream commit 4ed9dd7fde22ed614384c03f8049723cbe7e6a58 ] Fix a Coverity error that less-than-zero comparison of an unsigned value is never true. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240614034937.23978-1-shawn.sung@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit c0fd0eba42528c856b8c204e0f5d81af38a3598b Author: Geert Uytterhoeven Date: Wed Jun 26 10:41:44 2024 +0200 drm/panic: Do not select DRM_KMS_HELPER [ Upstream commit e044e707fc97dac693691178cdf41fe1a8da928f ] DRM core code cannot call into DRM helper code, as this would lead to circular references in the modular case. Hence drop the selection of DRM_KMS_HELPER. It was unused anyway, as v10 switched from using the DRM format helpers to its own color format conversion, cfr. commit 9544309775c3 ("drm/panic: Add support for color format conversion"). Remove the unneeded include of . Fixes: bf9fb17c6672 ("drm/panic: Add a drm panic handler") Signed-off-by: Geert Uytterhoeven Reviewed-by: Jocelyn Falempe Signed-off-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/60155f8c939ed286e324a7c12a1daa69fe49fcf6.1719391132.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit d6f36acfc45884b78655ce9a31a984f21637bfe0 Author: Jocelyn Falempe Date: Thu Jun 13 17:40:16 2024 +0200 drm/panic: depends on !VT_CONSOLE [ Upstream commit 1ac6ac9ec069ed0cfdb1c207ae23f6c40ac57437 ] The race condition between fbcon and drm_panic can only occurs if VT_CONSOLE is set. So update drm_panic dependency accordingly. This will make it easier for Linux distributions to enable drm_panic by disabling VT_CONSOLE, and keeping fbcon terminal. The only drawback is that fbcon won't display the boot kmsg, so it should rely on userspace to do that. At least plymouth already handle this case with https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224 Suggested-by: Daniel Vetter Signed-off-by: Jocelyn Falempe Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240613154041.325964-1-jfalempe@redhat.com Stable-dep-of: e044e707fc97 ("drm/panic: Do not select DRM_KMS_HELPER") Signed-off-by: Sasha Levin commit c53e98ef0372296ae357d83958d03114e5a180cd Author: Luca Ceresoli Date: Tue Jun 25 10:34:38 2024 +0200 Revert "leds: led-core: Fix refcount leak in of_led_get()" [ Upstream commit 940b27161afc6ec53fc66245a4fb3518394cdc92 ] This reverts commit da1afe8e6099980fe1e2fd7436dca284af9d3f29. Commit 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()"), introduced in 5.5, added of_led_get() and led_put() but missed a put_device() in led_put(), thus creating a leak in case the consumer device is removed. Arguably device removal was not very popular, so this went apparently unnoticed until 2022. In January 2023 two different patches got merged to fix the same bug: - commit da1afe8e6099 ("leds: led-core: Fix refcount leak in of_led_get()") - commit 445110941eb9 ("leds: led-class: Add missing put_device() to led_put()") They fix the bug in two different ways, which creates no patch conflicts, and both were merged in v6.2. The result is that now there is one more put_device() than get_device()s, instead of one less. Arguably device removal is not very popular yet, so this apparently hasn't been noticed as well up to now. But it blew up here while I'm working with device tree overlay insertion and removal. The symptom is an apparently unrelated list of oopses on device removal, with reasons: kernfs: can not remove 'uevent', no directory kernfs: can not remove 'brightness', no directory kernfs: can not remove 'max_brightness', no directory ... Here sysfs fails removing attribute files, which is because the device name changed and so the sysfs path. This is because the device name string got corrupted, which is because it got freed too early and its memory reused. Different symptoms could appear in different use cases. Fix by removing one of the two fixes. The choice was to remove commit da1afe8e6099 because: * it is calling put_device() inside of_led_get() just after getting the device, thus it is basically not refcounting the LED device at all during its entire lifetime * it does not add a corresponding put_device() in led_get(), so it fixes only the OF case The other fix (445110941eb9) is adding the put_device() in led_put() so it covers the entire lifetime, and it works even in the non-DT case. Fixes: da1afe8e6099 ("leds: led-core: Fix refcount leak in of_led_get()") Co-developed-by: Hervé Codina Signed-off-by: Hervé Codina Signed-off-by: Luca Ceresoli Link: https://lore.kernel.org/r/20240625-led-class-device-leak-v2-1-75fdccf47421@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 2862ec16f508527289edc6d418ce9bee7305f17b Author: Anjelique Melendez Date: Thu Jun 6 17:52:50 2024 -0700 leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggers [ Upstream commit 7e776e21255bf4c271e0df0a7d289a4963580e61 ] Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger() when setting brightness regardless of if they support PPG and have PBS triggers. Check if device supports PPG before setting/clearing PBS triggers. Fixes: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM") Fixes: 5e9ff626861a ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM") Signed-off-by: Anjelique Melendez Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240607005250.4047135-1-quic_amelende@quicinc.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit d4c57354a06cb4a77998ff8aa40af89eee30e07b Author: Chen Ni Date: Fri Jun 21 15:10:31 2024 +0800 drm/qxl: Add check for drm_cvt_mode [ Upstream commit 7bd09a2db0f617377027a2bb0b9179e6959edff3 ] Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function") Signed-off-by: Chen Ni Reviewed-by: Heng Qi Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240621071031.1987974-1-nichen@iscas.ac.cn Signed-off-by: Sasha Levin commit 7b232168841a3cf1f87245721084ea2fdf32491d Author: Lucas Stach Date: Fri Jun 21 19:11:06 2024 +0200 drm/etnaviv: fix DMA direction handling for cached RW buffers [ Upstream commit 58979ad6330a70450ed78837be3095107d022ea9 ] The dma sync operation needs to be done with DMA_BIDIRECTIONAL when the BO is prepared for both read and write operations. Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver") Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel Reviewed-by: Christian Gmeiner Signed-off-by: Sasha Levin commit 01723f9a60b4e3512a314a99c7cbc7795c3fa5bd Author: Namhyung Kim Date: Fri Jun 21 10:05:25 2024 -0700 perf report: Fix condition in sort__sym_cmp() [ Upstream commit cb39d05e67dc24985ff9f5150e71040fa4d60ab8 ] It's expected that both hist entries are in the same hists when comparing two. But the current code in the function checks one without dso sort key and other with the key. This would make the condition true in any case. I guess the intention of the original commit was to add '!' for the right side too. But as it should be the same, let's just remove it. Fixes: 69849fc5d2119 ("perf hists: Move sort__has_dso into struct perf_hpp_list") Reviewed-by: Kan Liang Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240621170528.608772-2-namhyung@kernel.org Signed-off-by: Sasha Levin commit da17ee4015c64002f690ce671a11f5f6afbf1cf7 Author: Junhao He Date: Fri Jun 14 17:43:18 2024 +0800 perf pmus: Fixes always false when compare duplicates aliases [ Upstream commit dd9a426eade634bf794c7e0f1b0c6659f556942f ] In the previous loop, all the members in the aliases[j-1] have been freed and set to NULL. But in this loop, the function pmu_alias_is_duplicate() compares the aliases[j] with the aliases[j-1] that has already been disposed, so the function will always return false and duplicate aliases will never be discarded. If we find duplicate aliases, it skips the zfree aliases[j], which is accompanied by a memory leak. We can use the next aliases[j+1] to theck for duplicate aliases to fixes the aliases NULL pointer dereference, then goto zfree code snippet to release it. After patch testing: $ perf list --unit=hisi_sicl,cpa pmu uncore cpa: cpa_p0_rd_dat_32b [Number of read ops transmitted by the P0 port which size is 32 bytes. Unit: hisi_sicl,cpa] cpa_p0_rd_dat_64b [Number of read ops transmitted by the P0 port which size is 64 bytes. Unit: hisi_sicl,cpa] Fixes: c3245d2093c1 ("perf pmu: Abstract alias/event struct") Signed-off-by: Junhao He Cc: ravi.bangoria@amd.com Cc: james.clark@arm.com Cc: prime.zeng@hisilicon.com Cc: cuigaosheng1@huawei.com Cc: jonathan.cameron@huawei.com Cc: linuxarm@huawei.com Cc: yangyicong@huawei.com Cc: robh@kernel.org Cc: renyu.zj@linux.alibaba.com Cc: kjain@linux.ibm.com Cc: john.g.garry@oracle.com Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240614094318.11607-1-hejunhao3@huawei.com Signed-off-by: Sasha Levin commit ee0a02229380f4ac1ffbda1cb19e29e6a12f968a Author: Athira Rajeev Date: Sun Jun 23 12:18:48 2024 +0530 tools/perf: Fix the string match for "/tmp/perf-$PID.map" files in dso__load [ Upstream commit b0979f008f1352a44cd3c8877e3eb8a1e3e1c6f3 ] Perf test for perf probe of function from different CU fails as below: ./perf test -vv "test perf probe of function from different CU" 116: test perf probe of function from different CU: --- start --- test child forked, pid 2679 Failed to find symbol foo in /tmp/perf-uprobe-different-cu-sh.Msa7iy89bx/testfile Error: Failed to add events. --- Cleaning up --- "foo" does not hit any event. Error: Failed to delete events. ---- end(-1) ---- 116: test perf probe of function from different CU : FAILED! The test does below to probe function "foo" : # gcc -g -Og -flto -c /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-foo.c -o /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-foo.o # gcc -g -Og -c /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-main.c -o /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-main.o # gcc -g -Og -o /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-foo.o /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile-main.o # ./perf probe -x /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile foo Failed to find symbol foo in /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7/testfile Error: Failed to add events. Perf probe fails to find symbol foo in the executable placed in /tmp/perf-uprobe-different-cu-sh.XniNxNEVT7 Simple reproduce: # mktemp -d /tmp/perf-checkXXXXXXXXXX /tmp/perf-checkcWpuLRQI8j # gcc -g -o test test.c # cp test /tmp/perf-checkcWpuLRQI8j/ # nm /tmp/perf-checkcWpuLRQI8j/test | grep foo 00000000100006bc T foo # ./perf probe -x /tmp/perf-checkcWpuLRQI8j/test foo Failed to find symbol foo in /tmp/perf-checkcWpuLRQI8j/test Error: Failed to add events. But it works with any files like /tmp/perf/test. Only for patterns with "/tmp/perf-", this fails. Further debugging, commit 80d496be89ed ("perf report: Add support for profiling JIT generated code") added support for profiling JIT generated code. This patch handles dso's of form "/tmp/perf-$PID.map" . The check used "if (strncmp(self->name, "/tmp/perf-", 10) == 0)" to match "/tmp/perf-$PID.map". With this commit, any dso in /tmp/perf- folder will be considered separately for processing (not only JIT created map files ). Fix this by changing the string pattern to check for "/tmp/perf-%d.map". Add a helper function is_perf_pid_map_name to do this check. In "struct dso", dso->long_name holds the long name of the dso file. Since the /tmp/perf-$PID.map check uses the complete name, use dso___long_name for the string name. With the fix, # ./perf test "test perf probe of function from different CU" 117: test perf probe of function from different CU : Ok Fixes: 56cbeacf1435 ("perf probe: Add test for regression introduced by switch to die_get_decl_file()") Signed-off-by: Athira Rajeev Reviewed-by: Chaitanya S Prakash Reviewed-by: Adrian Hunter Cc: akanksha@linux.ibm.com Cc: kjain@linux.ibm.com Cc: maddy@linux.ibm.com Cc: disgoel@linux.vnet.ibm.com Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240623064850.83720-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 46a62b1cbca957e6013320af3ef77a19221df3f7 Author: James Clark Date: Wed Jun 12 15:03:14 2024 +0100 perf test: Make test_arm_callgraph_fp.sh more robust [ Upstream commit ff16aeb9b83441b8458d4235496cf320189a0c60 ] The 2 second sleep can cause the test to fail on very slow network file systems because Perf ends up being killed before it finishes starting up. Fix it by making the leafloop workload end after a fixed time like the other workloads so there is no need to kill it after 2 seconds. Also remove the 1 second start sampling delay because it is similarly fragile. Instead, search through all samples for a matching one, rather than just checking the first sample and hoping it's in the right place. Fixes: cd6382d82752 ("perf test arm64: Test unwinding using fame-pointer (fp) mode") Signed-off-by: James Clark Acked-by: Namhyung Kim Cc: German Gomez Cc: Spoorthy S Cc: Kajol Jain Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240612140316.3006660-1-james.clark@arm.com Signed-off-by: Sasha Levin commit eb049d63ba11f2c9c3b5a26feb98141319e69aa5 Author: Dmitry Baryshkov Date: Mon Jun 24 18:08:12 2024 +0300 platform/arm64: build drivers even on non-ARM64 platforms [ Upstream commit 13bbe1c83bc401c2538c758228d27b4042b08341 ] The Kconfig for platforms/arm64 has 'depends on ARM64 || COMPILE_TEST'. However due to Makefile having just obj-$(CONFIG_ARM64) the subdir will not be descended for !ARM64 platforms and thus the drivers won't get built. This breaks modular builds of other driver drivers which depend on arm64 platform drivers. Reported-by: Greg Kroah-Hartman Fixes: 363c8aea2572 ("platform: Add ARM64 platform directory") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240624-ucsi-yoga-ec-driver-v9-1-53af411a9bd6@linaro.org Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin commit 31b6cd5545f133be3838a6d16520e9277d6056cc Author: Geert Uytterhoeven Date: Thu Jun 13 21:18:00 2024 +0200 drm/panic: Fix off-by-one logo size checks [ Upstream commit 94ff11d3bd32506710ca43569d38420e7fc790c1 ] Logos that are either just as wide or just as high as the display work fine. Fixes: bf9fb17c6672868d ("drm/panic: Add a drm panic handler") Signed-off-by: Geert Uytterhoeven Reviewed-by: Jocelyn Falempe Signed-off-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/1c9d02463cef3eac22cfac3ac6d1adad369f367b.1718305355.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 1d5d55b29999afe9843c961f313169ba9b1eb7ab Author: Jocelyn Falempe Date: Mon Jun 3 11:47:25 2024 +0200 drm/panic: only draw the foreground color in drm_panic_blit() [ Upstream commit eef5a55af31792fc7a2082dbebac68a7df4d7643 ] The whole framebuffer is cleared, so it's useless to rewrite the background colored pixels. It allows to simplify the drawing functions, and prepare the work for the set_pixel() callback. v2: * keep fg16/fg24/fg32 as variable name for the blit function. * add drm_panic_is_pixel_fg() to avoid code duplication. both suggested by Javier Martinez Canillas Signed-off-by: Jocelyn Falempe Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240603095343.39588-2-jfalempe@redhat.com Stable-dep-of: 94ff11d3bd32 ("drm/panic: Fix off-by-one logo size checks") Signed-off-by: Sasha Levin commit b9080795fe80e385a53ec63ef4f5ff25e1e467d3 Author: Karolina Stolarek Date: Wed Jun 12 14:02:55 2024 +0200 drm/ttm/tests: Fix a warning in ttm_bo_unreserve_bulk [ Upstream commit 588c4c8d58c413b52c68193bdb741cfbf1040a77 ] BOs in a bulk move have to share the same reservation object. That is not the case in the ttm_bo_unreserve_bulk subtest. Update ttm_bo_kunit_init() helper to accept dma_resv object so we can define buffer objects that share the same resv. Update calls to that helper accordingly. Fixes: 995279d280d1 ("drm/ttm/tests: Add tests for ttm_bo functions") Suggested-by: Christian König Signed-off-by: Karolina Stolarek Reviewed-by: Thomas Hellström Signed-off-by: Arunpravin Paneer Selvam Link: https://patchwork.freedesktop.org/patch/msgid/c5bd2df114781b4eb5c1e8295b2ae4ac2c30a179.1718192625.git.karolina.stolarek@intel.com Signed-off-by: Sasha Levin commit aa6e78f2c87d93ef83ed0e6a311ca063d5e8998b Author: Abhinav Kumar Date: Thu Jun 20 13:17:30 2024 -0700 drm/msm/dpu: drop validity checks for clear_pending_flush() ctl op [ Upstream commit 3d68e3dedd4b48f0358bdc187277e3315d8aa559 ] clear_pending_flush() ctl op is always assigned irrespective of the DPU hardware revision. Hence there is no needed to check whether the op has been assigned before calling it. Drop the checks across the driver for clear_pending_flush() and also update its documentation that it is always expected to be assigned. changes in v2: - instead of adding more validity checks just drop the one for clear_pending_flush - update the documentation for clear_pending_flush() ctl op - update the commit text reflecting these changes changes in v3: - simplify the documentation of clear_pending_flush Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/464fbd84-0d1c-43c3-a40b-31656ac06456@moroto.mountain/T/ Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/600241/ Link: https://lore.kernel.org/r/20240620201731.3694593-1-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0bdec11134cc93171c33e7844e841e245ef10d13 Author: Jonathan Marek Date: Thu May 30 13:56:49 2024 +0800 drm/msm/dsi: set VIDEO_COMPRESSION_MODE_CTRL_WC [ Upstream commit 9ecd0ddd223b68b4603e4766a1d51f6c6cda346e ] Video mode DSC won't work if this field is not set correctly. Set it to fix video mode DSC (for slice_per_pkt==1 cases at least). Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by: Jonathan Marek Reviewed-by: Dmitry Baryshkov Signed-off-by: Jun Nie Tested-by: Neil Armstrong # on SM8550-QRD Tested-by: Neil Armstrong # on SM8650-QRD Tested-by: Neil Armstrong # on SM8650-HDK Reviewed-by: Jessica Zhang Patchwork: https://patchwork.freedesktop.org/patch/596234/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-5-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 2afd0e9059d5b60585fa52bd3aa0890ca1124b71 Author: Jonathan Marek Date: Thu May 30 13:56:48 2024 +0800 drm/msm/dsi: set video mode widebus enable bit when widebus is enabled [ Upstream commit 007870b8eaf54739c7b417ddaf90bf364b7e4bc8 ] The value returned by msm_dsi_wide_bus_enabled() doesn't match what the driver is doing in video mode. Fix that by actually enabling widebus for video mode. Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI") Signed-off-by: Jonathan Marek Reviewed-by: Dmitry Baryshkov Reviewed-by: Marijn Suijten Reviewed-by: Jessica Zhang Signed-off-by: Jun Nie Tested-by: Neil Armstrong # on SM8550-QRD Tested-by: Neil Armstrong # on SM8650-QRD Tested-by: Neil Armstrong # on SM8650-HDK Patchwork: https://patchwork.freedesktop.org/patch/596232/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-4-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 0788a6f3523d3686a9eed5ea1e6fcce6841277b2 Author: Hans de Goede Date: Sat May 4 18:25:33 2024 +0200 leds: trigger: Unregister sysfs attributes before calling deactivate() [ Upstream commit c0dc9adf9474ecb7106e60e5472577375aedaed3 ] Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). Fixes: a7e7a3156300 ("leds: triggers: add device attribute support") Cc: Uwe Kleine-König Signed-off-by: Hans de Goede Acked-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e6daf3bf851b43f6f683c7295b868e66ab255df2 Author: Ming Qian Date: Thu Oct 19 16:36:36 2023 +0800 media: imx-jpeg: Drop initial source change event if capture has been setup [ Upstream commit a8fb5fce7a441d37d106c82235e1f1b57f70f5b9 ] In section 4.5.1.5. Initialization, the step 4 may be skipped and continue with the Capture Setup sequence, so if the capture has been setup, there is no need to trigger the initial source change event, just start decoding, and follow the dynamic resolution change flow if the configured values do not match those parsed by the decoder. And it won't fail the gstreamer pipeline. Fixes: b833b178498d ("media: imx-jpeg: notify source chagne event when the first picture parsed") Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit d371e4eed3117f94650519fe7e2751df685c2247 Author: Konrad Dybcio Date: Thu Jun 6 13:10:49 2024 +0200 drm/msm/a6xx: Fix A702 UBWC mode [ Upstream commit 593f1dd4c81f6932042508a80186dbdea90312a5 ] UBWC_MODE is a one-bit-wide field, so a value of 2 is obviously bogus. Replace it with the correct value (0). Fixes: 18397519cb62 ("drm/msm/adreno: Add A702 support") Reported-by: Connor Abbott Closes: https://lore.kernel.org/linux-arm-msm/CACu1E7FTN=kwaDJMNiTmFspALzj2+Q-nvsN5ugi=vz4RdUGvGw@mail.gmail.com/ Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/597359/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit faedf1281d28f9e6bab79d60e1ee9338f35c1179 Author: Abhinav Kumar Date: Wed Jun 5 11:34:15 2024 -0700 drm/msm/a6xx: use __unused__ to fix compiler warnings for gen7_* includes [ Upstream commit 71d9b458b2bfe79197194d914aa9bada46fb9e14 ] GCC diagnostic pragma method throws below warnings in some of the versions drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:16:9: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas] #pragma GCC diagnostic ignored "-Wunused-const-variable" ^ In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:18:0: drivers/gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h:924:19: warning: 'gen7_0_0_external_core_regs' defined but not used [-Wunused-variable] static const u32 *gen7_0_0_external_core_regs[] = { ^ In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:19:0: drivers/gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h:748:19: warning: 'gen7_2_0_external_core_regs' defined but not used [-Wunused-variable] static const u32 *gen7_2_0_external_core_regs[] = { ^ In file included from drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:20:0: drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1188:43: warning: 'gen7_9_0_sptp_clusters' defined but not used [-Wunused-variable] static struct gen7_sptp_cluster_registers gen7_9_0_sptp_clusters[] = { ^ drivers/gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h:1438:19: warning: 'gen7_9_0_external_core_regs' defined but not used [-Wunused-variable] static const u32 *gen7_9_0_external_core_regs[] = { Remove GCC version dependency by using __unused__ for the unused gen7_* includes. Changes in v2: - Fix the warnings in the commit text - Use __attribute((__unused__)) instead of local assignment changes in v3: - drop the Link from the auto add changes in v4: - replace __attribute((__unused__)) with __always_unused Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx") Suggested-by: Rob Clark Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/597265/ [Add gen7_9_0_cx_debugbus_blocks as well] Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 8a4ce184dcc6e8e0fb7745d9ff9646bbd3db678d Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:50 2024 +0800 drm/mediatek: Set DRM mode configs accordingly [ Upstream commit a4c9410b31cac463599898edb5111ca9bc0810bd ] Set DRM mode configs limitation according to the hardware capabilities and pass the IGT checks as below: - The test "graphics.IgtKms.kms_plane" requires a frame buffer with width of 4512 pixels (> 4096). - The test "graphics.IgtKms.kms_cursor_crc" checks if the cursor size is defined, and run the test with cursor size from 1x1 to 512x512. Please notice that the test conditions may change as IGT is updated. Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-10-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 0d4c45d40198094785afd39b56463eeeb5a1803a Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:48 2024 +0800 drm/mediatek: Add DRM_MODE_ROTATE_0 to rotation property [ Upstream commit 74608d8feefd1675388f23362aac8df4ac3af931 ] Always add DRM_MODE_ROTATE_0 to rotation property to meet IGT's (Intel GPU Tools) requirement. Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-8-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 19ef723f6edd6345a13f3f7686f0ede7400a2109 Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:47 2024 +0800 drm/mediatek: Add OVL compatible name for MT8195 [ Upstream commit 6fb7a0985fd16868b5d72eb3e3de7524a6000e6e ] Add OVL compatible name for MT8195. Without this commit, DRM won't work after modifying the device tree. Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-7-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit a063acc5d33d655dc9504e54d5debcac9919837d Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:46 2024 +0800 drm/mediatek: Turn off the layers with zero width or height [ Upstream commit 6b9946f4550d8dad8bc1af2db97286ca449af786 ] We found that IGT (Intel GPU Tool) will try to commit layers with zero width or height and lead to undefined behaviors in hardware. Disable the layers in such a situation. Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-6-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 5e28b7aa8be1444781077ea8301c8d938343f109 Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:45 2024 +0800 drm/mediatek: Fix destination alpha error in OVL [ Upstream commit 31c0fbf67c8c0bb38d7fb21d404ea3dbd619d99e ] The formula of Coverage alpha blending is: dst.a = dst.a * (0xff - src.a * SCA / 0xff) / 0xff + src.a * SCA / 0xff dst.a: destination alpha src.a: pixel alpha SCA : plane alpha When SCA = 0xff, the formula becomes: dst.a = dst.a * (0xff - src.a) + src.a This patch is to set the destination alpha (background) to 0xff: - When dst.a = 0 (before), dst.a = src.a - When dst.a = 0xff (after) , dst.a = 0xff * (0xff - src.a) + src.a According to the fomula above: - When src.a = 0 , dst.a = 0 - When src.a = 0xff, dst.a = 0xff This two cases are just still correct. But when src.a is between 0 and 0xff, the difference starts to appear Fixes: 616443ca577e ("drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub driver private data") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-5-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 8c3411d859f1615467592b38dab11ac20cc9185a Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:44 2024 +0800 drm/mediatek: Fix XRGB setting error in Mixer [ Upstream commit 8e418bee401b7cfd0bc40d187afea2c6b08b44ec ] Although the alpha channel in XRGB formats can be ignored, ALPHA_CON must be configured accordingly when using XRGB formats or it will still affects CRC generation. Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-4-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 91ef5af76f7ec7383930d2884856808d707c527d Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:43 2024 +0800 drm/mediatek: Fix XRGB setting error in OVL [ Upstream commit 765f284f1fe172573021056f7e337ee53f252969 ] CONST_BLD must be enabled for XRGB formats although the alpha channel can be ignored, or OVL will still read the value from memory. This error only affects CRC generation. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-3-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit a2541f21713f76508f25782832e6fe7c8bcb53b5 Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:42 2024 +0800 drm/mediatek: Use 8-bit alpha in ETHDR [ Upstream commit 231c020141cb150a59f5b28379cad82ff7bad899 ] 9-bit alpha (max=0x100) is designed for special HDR related calculation, which should be disabled by default. Change the alpha value from 0x100 to 0xff in 8-bit form. Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-2-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 0e2b6d89ae144445ab9eae0c7fee69ea9bfca7a5 Author: Hsiao Chien Sung Date: Thu Jun 20 00:38:41 2024 +0800 drm/mediatek: Add missing plane settings when async update [ Upstream commit 86b89dc669c400576dc23aa923bcf302f99e8e3a ] Fix an issue that plane coordinate was not saved when calling async update. Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic update") Reviewed-by: CK Hu Reviewed-by: AngeloGioacchino Del Regno Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-1-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 41b97b3d61a0b2857f8392ca7406cd944e3c55ec Author: Sebastian Andrzej Siewior Date: Wed Jun 19 16:46:30 2024 +0200 drm/ttm/tests: Let ttm_bo_test consider different ww_mutex implementation. [ Upstream commit f85376c890ef470b64a7fea22eea5af18822f05c ] PREEMPT_RT has a different locking implementation for ww_mutex. The base mutex of struct ww_mutex is declared as struct WW_MUTEX_BASE. The latter is defined as `mutex' for non-PREEMPT_RT builds and `rt_mutex' for PREEMPT_RT builds. Using mutex_lock() directly on the base mutex in ttm_bo_reserve_deadlock() leads to compile error on PREEMPT_RT. The locking-selftest has its own defines to deal with this and it is probably best to defines the needed one within the test program since their usefulness is limited outside of well known selftests. Provide ww_mutex_base_lock() which points to the correct function for PREEMPT_RT and non-PREEMPT_RT builds. Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240619144630.4DliKOmr@linutronix.de Signed-off-by: Sasha Levin commit 0f2a77c69b193e81af38ef1e75d191be74ec4ce0 Author: Laurent Pinchart Date: Sun Nov 19 03:11:51 2023 +0200 media: renesas: vsp1: Store RPF partition configuration per RPF instance [ Upstream commit a213bc09b1025c771ee722ee341af1d84375db8a ] The vsp1_partition structure stores the RPF partition configuration in a single field for all RPF instances, while each RPF can have its own configuration. Fix it by storing the configuration separately for each RPF instance. Signed-off-by: Laurent Pinchart Fixes: ab45e8585182 ("media: v4l: vsp1: Allow entities to participate in the partition algorithm") Reviewed-by: Jacopo Mondi Signed-off-by: Sasha Levin commit f1fd968260da54fb7365bb28d68f85016ad692f6 Author: Laurent Pinchart Date: Sun May 5 20:22:27 2024 +0300 media: renesas: vsp1: Fix _irqsave and _irq mix [ Upstream commit 57edbbcf5258c378a9b9d0c80d33b03a010b22c8 ] The histogram support mixes _irqsave and _irq, causing the following smatch warning: drivers/media/platform/renesas/vsp1/vsp1_histo.c:153 histo_stop_streaming() warn: mixing irqsave and irq The histo_stop_streaming() calls spin_lock_irqsave() followed by wait_event_lock_irq(). The former hints that interrupts may be disabled by the caller, while the latter reenables interrupts unconditionally. This doesn't cause any real bug, as the function is always called with interrupts enabled, but the pattern is still incorrect. Fix the problem by using spin_lock_irq() instead of spin_lock_irqsave() in histo_stop_streaming(). While at it, switch to spin_lock_irq() and spin_lock() as appropriate elsewhere. Fixes: 99362e32332b ("[media] v4l: vsp1: Add histogram support") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/linux-renesas-soc/164d74ff-312c-468f-be64-afa7182cd2f4@moroto.mountain/ Reviewed-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit c88ffbc568cbd3e6934f2804030a273923e015dd Author: Jacopo Mondi Date: Mon Jun 17 18:11:26 2024 +0200 media: rcar-csi2: Cleanup subdevice in remove() [ Upstream commit f6d64d0d2897ed4e85ac00afe43e45c8b8fc0c44 ] Cleanup the V4L2 subdevice in the driver's remove function to ensure its async connection are freed, and guarantee in future that the subdev active state is cleaned up. Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Reviewed-by: Niklas Söderlund Tested-by: Niklas Söderlund Link: https://lore.kernel.org/r/20240617161135.130719-4-jacopo.mondi@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 484f18269e799d183f81de3609409ba847ce14e3 Author: Jacopo Mondi Date: Mon Jun 17 18:11:25 2024 +0200 media: rcar-csi2: Disable runtime_pm in probe error [ Upstream commit e306183628f7c2e95f9bf853d8fcb86288f606de ] Disable pm_runtime in the probe() function error path. Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver") Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Reviewed-by: Niklas Söderlund Tested-by: Niklas Söderlund Link: https://lore.kernel.org/r/20240617161135.130719-3-jacopo.mondi@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 7dd4dba5dc103f70af1f3977a308f41354cab8a7 Author: Jacopo Mondi Date: Mon Jun 17 18:11:24 2024 +0200 media: rcar-vin: Fix YUYV8_1X16 handling for CSI-2 [ Upstream commit 9caf253e8ad6f4c66f5591bac900f9f68b6b6620 ] The YUYV8_1X16 and UYVY8_1X16 formats are treated as 'ITU-R BT.601/BT.1358 16-bit YCbCr-422 input' (YUV16 - 0x5) in the R-Car VIN driver and are thus disallowed when capturing frames from the R-Car CSI-2 interface according to the hardware manual. As the 1X16 format variants are meant to be used with serial busses they have to be treated as 'YCbCr-422 8-bit data input' (0x1) when capturing from CSI-2, which is a valid setting for CSI-2. Commit 78b3f9d75a62 ("media: rcar-vin: Add check that input interface and format are valid") disallowed capturing YUV16 when using the CSI-2 interface. Fix this by using YUV8_BT601 for YCbCr422 when CSI-2 is in use. Fixes: 78b3f9d75a62 ("media: rcar-vin: Add check that input interface and format are valid") Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Reviewed-by: Niklas Söderlund Tested-by: Niklas Söderlund Link: https://lore.kernel.org/r/20240617161135.130719-2-jacopo.mondi@ideasonboard.com Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit a749415d2058a9e34c1cc16e12e2ae16057525a5 Author: Jouni Högander Date: Tue Jun 18 08:30:18 2024 +0300 drm/i915/psr: Set SU area width as pipe src width [ Upstream commit 97db7348640ececd60a0bfd85b6c0a3a0f81459a ] Currently SU area width is set as MAX_INT. This is causing problems. Instead set it as pipe src width. Fixes: 86b26b6aeac7 ("drm/i915/psr: Carry su area in crtc_state") Signed-off-by: Jouni Högander Reviewed-by: Mika Kahola Link: https://patchwork.freedesktop.org/patch/msgid/20240618053026.3268759-2-jouni.hogander@intel.com Signed-off-by: Sasha Levin commit 475c678426b15c99dfb8324ef82174578020ba81 Author: Sean Anderson Date: Fri May 3 15:29:13 2024 -0400 drm: zynqmp_kms: Fix AUX bus not getting unregistered [ Upstream commit 0743dafefd3f2b92116213f2225ea355001b7948 ] drm_encoder_cleanup is responsible for calling drm_bridge_detach for each bridge attached to the encoder. zynqmp_dp_bridge_detach is in turn responsible for unregistering the AUX bus. However, we never ended up calling drm_encoder_cleanup in the remove or error paths, so the AUX bus would stick around after the rest of the driver had been removed. I don't really understand why drm_mode_config_cleanup doesn't call drm_encoder_cleanup for us. It will call destroy (which for simple_encoder is drm_encoder_cleanup) on encoders in the mode_config's encoder_list. Should drm_encoder_cleanup get called before or after drm_atomic_helper_shutdown? Fixes: 2dfd045c8435 ("drm: xlnx: zynqmp_dpsub: Register AUX bus at bridge attach time") Signed-off-by: Sean Anderson Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240503192922.2172314-2-sean.anderson@linux.dev Signed-off-by: Sasha Levin commit 8c07f6b2abda30006df4e5d259a35cf15ae0d5e9 Author: Christophe JAILLET Date: Mon May 20 11:40:37 2024 +0200 drm: zynqmp_dpsub: Fix an error handling path in zynqmp_dpsub_probe() [ Upstream commit 4ea3deda1341fef7b923ad9cfe5dd46b1b51bfa8 ] If zynqmp_dpsub_drm_init() fails, we must undo the previous drm_bridge_add() call. Fixes: be3f3042391d ("drm: zynqmp_dpsub: Always register bridge") Signed-off-by: Christophe JAILLET Reviewed-by: Sean Anderson Reviewed-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/974d1b062d7c61ee6db00d16fa7c69aa1218ee02.1716198025.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 0f12d2b6e6118a6e73af44bc10f053ffb11dd50f Author: Daniel Schaefer Date: Sun Jun 2 14:50:53 2024 +0800 media: uvcvideo: Override default flags [ Upstream commit 86419686e66da5b90a07fb8a40ab138fe97189b5 ] When the UVC device has a control that is readonly it doesn't set the SET_CUR flag. For example the privacy control has SET_CUR flag set in the defaults in the `uvc_ctrls` variable. Even if the device does not have it set, it's not cleared by uvc_ctrl_get_flags(). Originally written with assignment in commit 859086ae3636 ("media: uvcvideo: Apply flags from device to actual properties"). But changed to |= in commit 0dc68cabdb62 ("media: uvcvideo: Prevent setting unavailable flags"). It would not clear the default flags. With this patch applied the correct flags are reported to user space. Tested with: ``` > v4l2-ctl --list-ctrls | grep privacy privacy 0x009a0910 (bool) : default=0 value=0 flags=read-only ``` Signed-off-by: Daniel Schaefer Fixes: 0dc68cabdb62 ("media: uvcvideo: Prevent setting unavailable flags") Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240602065053.36850-1-dhs@frame.work Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 35a00891b0c222ec4f823aa2c4673b5d3a1eb126 Author: Oleksandr Natalenko Date: Mon Mar 25 15:26:11 2024 +0100 media: uvcvideo: Add quirk for invalid dev_sof in Logitech C920 [ Upstream commit 85fbe91a7c9210bb30638846b551fa5d3cb7bc4c ] Similarly to Logitech C922, C920 seems to also suffer from a firmware bug that breaks hardware timestamping. Add a quirk for this camera model too. Before applying the quirk: ``` 100 (4) [-] none 100 200717 B 212.919114 213.079004 33.727 fps ts mono/SoE 101 (5) [-] none 101 200889 B 213.003703 213.114996 11.822 fps ts mono/SoE 102 (6) [-] none 102 200926 B 213.035571 213.146999 31.379 fps ts mono/SoE 103 (7) [-] none 103 200839 B 213.067424 213.179003 31.394 fps ts mono/SoE 104 (0) [-] none 104 200692 B 213.293180 213.214991 4.430 fps ts mono/SoE 105 (1) [-] none 105 200937 B 213.322374 213.247001 34.254 fps ts mono/SoE 106 (2) [-] none 106 201013 B 213.352228 213.279005 33.496 fps ts mono/SoE … ``` After applying the quirk: ``` 154 (2) [-] none 154 192417 B 42.199823 42.207788 27.779 fps ts mono/SoE 155 (3) [-] none 155 192040 B 42.231834 42.239791 31.239 fps ts mono/SoE 156 (4) [-] none 156 192213 B 42.263823 42.271822 31.261 fps ts mono/SoE 157 (5) [-] none 157 191981 B 42.299824 42.303827 27.777 fps ts mono/SoE 158 (6) [-] none 158 191953 B 42.331835 42.339811 31.239 fps ts mono/SoE 159 (7) [-] none 159 191904 B 42.363824 42.371813 31.261 fps ts mono/SoE 160 (0) [-] none 160 192210 B 42.399834 42.407801 27.770 fps ts mono/SoE ``` Fixes: 5d0fd3c806b9 ("[media] uvcvideo: Disable hardware timestamps by default") Signed-off-by: Oleksandr Natalenko Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240325142611.15550-1-oleksandr@natalenko.name Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 27e991a926212a8d64db6df6df04734aee11a35b Author: Ricardo Ribalda Date: Sat Mar 23 10:48:04 2024 +0000 media: uvcvideo: Quirk for invalid dev_sof in Logitech C922 [ Upstream commit 9183c6f1a21e0da4415762c504e2d7f784304d12 ] Logitech C922 internal SOF does not increases at a stable rate of 1kHz. This causes that the device_sof and the host_sof run at different rates, breaking the clock domain conversion algorithm. Eg: 30 (6) [-] none 30 614400 B 21.245557 21.395214 34.133 fps ts mono/SoE 31 (7) [-] none 31 614400 B 21.275327 21.427246 33.591 fps ts mono/SoE 32 (0) [-] none 32 614400 B 21.304739 21.459256 34.000 fps ts mono/SoE 33 (1) [-] none 33 614400 B 21.334324 21.495274 33.801 fps ts mono/SoE * 34 (2) [-] none 34 614400 B 21.529237 21.527297 5.130 fps ts mono/SoE * 35 (3) [-] none 35 614400 B 21.649416 21.559306 8.321 fps ts mono/SoE 36 (4) [-] none 36 614400 B 21.678789 21.595320 34.045 fps ts mono/SoE ... 99 (3) [-] none 99 614400 B 23.542226 23.696352 33.541 fps ts mono/SoE 100 (4) [-] none 100 614400 B 23.571578 23.728404 34.069 fps ts mono/SoE 101 (5) [-] none 101 614400 B 23.601425 23.760420 33.504 fps ts mono/SoE * 102 (6) [-] none 102 614400 B 23.798324 23.796428 5.079 fps ts mono/SoE * 103 (7) [-] none 103 614400 B 23.916271 23.828450 8.478 fps ts mono/SoE 104 (0) [-] none 104 614400 B 23.945720 23.860479 33.957 fps ts mono/SoE Instead of disabling completely the hardware timestamping for such hardware we take the assumption that the packet handling jitter is under 2ms and use the host_sof as dev_sof. We can think of the UVC hardware clock as a system with a coarse clock (the SOF) and a fine clock (the PTS). The coarse clock can be replaced with a clock on the same frequency, if the jitter of such clock is smaller than its sampling rate. That way we can save some of the precision of the fine clock. To probe this point we have run three experiments on the Logitech C922. On that experiment we run the camera at 33fps and we analyse the difference in msec between a frame and its predecessor. If we display the histogram of that value, a thinner histogram will mean a better meassurement. The results for: - original hw timestamp: https://ibb.co/D1HJJ4x - pure software timestamp: https://ibb.co/QC9MgVK - modified hw timestamp: https://ibb.co/8s9dBdk This bug in the camera firmware has been confirmed by the vendor. lsusb -v Bus 001 Device 044: ID 046d:085c Logitech, Inc. C922 Pro Stream Webcam Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x046d Logitech, Inc. idProduct 0x085c C922 Pro Stream Webcam bcdDevice 0.16 iManufacturer 0 iProduct 2 C922 Pro Stream Webcam iSerial 1 80B912DF bNumConfigurations 1 Reviewed-by: Sergey Senozhatsky Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Reviewed-by: Ricardo Ribalda Signed-off-by: Oleksandr Natalenko Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20240323-resend-hwtimestamp-v10-3-b08e590d97c7@chromium.org Signed-off-by: Laurent Pinchart Stable-dep-of: 85fbe91a7c92 ("media: uvcvideo: Add quirk for invalid dev_sof in Logitech C920") Signed-off-by: Sasha Levin commit 0fe5ae08c1321b050b711017cb6ddbae92f0eb34 Author: Conor Dooley Date: Fri Jun 7 16:50:23 2024 +0100 media: i2c: imx219: fix msr access command sequence [ Upstream commit 3cdc776e0a5f1784c3ae5d3371b64215c228bf1f ] It was reported to me that the imx219 didn't work on one of our development kits partly because the access sequence is incorrect. The datasheet I could find [1] for this camera has the access sequence: Seq. No. Address (Hex) data 1 30EB 05 2 30EB 0C 3 300A FF 4 300B FF 5 30EB 05 6 30EB 09 but the driver swaps the first two elements. Laurent pointed out on IRC that the original code used the correct sequence for 1920x1080 but the current sequence for 3280x2464 and 1640x1232. During refactoring of the init sequence the current order was used for all formats. Switch to using the documented sequence. Link: https://www.opensourceinstruments.com/Electronics/Data/IMX219PQ.pdf [1] Fixes: 8508455961d5 ("media: i2c: imx219: Split common registers from mode tables") Fixes: 1283b3b8f82b ("media: i2c: Add driver for Sony IMX219 sensor") Signed-off-by: Conor Dooley Reviewed-by: Dave Stevenson Tested-by: Dave Stevenson Reviewed-by: Laurent Pinchart Tested-by: Adam Ford #imx8mp-beacon-kit Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 29649f3c5697e887fcc9e2c5e25d6e5134911a90 Author: Ricardo Ribalda Date: Thu Jun 6 13:01:07 2024 +0000 media: c8sectpfe: Add missing parameter names [ Upstream commit abb7a73b687dc82202f0203a112ef435fb598aa6 ] clang 19 complains about the missing parameter name. Let's add it. drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-debugfs.h:19:62: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202406050908.1kL1C69p-lkp@intel.com/ Fixes: e22b4973ee20 ("media: c8sectpfe: Do not depend on DEBUG_FS") Signed-off-by: Ricardo Ribalda Reviewed-by: Nathan Chancellor Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 97a80ca3dce374056fbc6578bf41ea22fc0e70e4 Author: Aleksandr Burakov Date: Fri Feb 16 15:40:06 2024 +0300 saa7134: Unchecked i2c_transfer function result fixed [ Upstream commit 9d8683b3fd93f0e378f24dc3d9604e5d7d3e0a17 ] Return value of function 'i2c_transfer' is not checked that may cause undefined behaviour. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2cf36ac44730 ("[PATCH] v4l: 656: added support for the following cards") Signed-off-by: Aleksandr Burakov Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 23f5e185134cf4c2c50320b72a622bb576c0a67c Author: Alex Deucher Date: Tue Jun 4 11:46:04 2024 -0400 drm/amd/display: use pre-allocated temp structure for bounding box [ Upstream commit afe9555e79fcd0d758e3796ad00fd6292d99361b ] This mirrors what the driver does for older DCN generations. Should fix: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 449, name: kworker/u64:8 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: ffffffffc0ce1580>] dc_fpu_begin+0x30/0xd0 [amdgpu] CPU: 5 PID: 449 Comm: kworker/u64:8 Tainted: G W 6.8.0+ #35 Hardware name: System manufacturer System Product Name/ROG STRIX X570-E GAMING WIFI II, BIOS 4204 02/24/2022 Workqueue: events_unbound async_run_entry_fn v2: drop extra memcpy Fixes: 88c61827cedc ("drm/amd/display: dynamically allocate dml2_configuration_options structures") Reviewed-by: Harry Wentland Tested-by: George Zhang (v1) Suggested-by: Hamza Mahfooz Signed-off-by: Alex Deucher Cc: George Zhang Cc: Arnd Bergmann Cc: harry.wentland@amd.com Cc: sunpeng.li@amd.com Cc: Rodrigo.Siqueira@amd.com Signed-off-by: Sasha Levin commit 898d200148d03cbaec0c63cd670445a2bb4a51a3 Author: Dan Carpenter Date: Fri Jun 14 20:30:44 2024 +0300 ipmi: ssif_bmc: prevent integer overflow on 32bit systems [ Upstream commit 0627cef36145c9ff9845bdfd7ddf485bbac1f981 ] There are actually two bugs here. First, we need to ensure that count is at least sizeof(u32) or msg.len will be uninitialized data. The "msg.len" variable is a u32 that comes from the user. On 32bit systems the "sizeof_field(struct ipmi_ssif_msg, len) + msg.len" addition can overflow if "msg.len" is greater than U32_MAX - 4. Valid lengths for "msg.len" are 1-254. Add a check for that to prevent the integer overflow. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Signed-off-by: Dan Carpenter Message-Id: <1431ca2e-4e9c-4520-bfc0-6879313c30e9@moroto.mountain> Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 5f8c27d3985edc7bdab84ca180dbc4f0edd4628f Author: Jiri Olsa Date: Wed Jun 12 08:44:27 2024 +0900 x86/shstk: Make return uprobe work with shadow stack [ Upstream commit 1713b63a07a28a475de94664f783b4cfd2e4fa90 ] Currently the application with enabled shadow stack will crash if it sets up return uprobe. The reason is the uretprobe kernel code changes the user space task's stack, but does not update shadow stack accordingly. Adding new functions to update values on shadow stack and using them in uprobe code to keep shadow stack in sync with uretprobe changes to user stack. Link: https://lore.kernel.org/all/20240611112158.40795-2-jolsa@kernel.org/ Acked-by: Andrii Nakryiko Acked-by: Rick Edgecombe Reviewed-by: Oleg Nesterov Fixes: 488af8ea7131 ("x86/shstk: Wire in shadow stack interface") Signed-off-by: Jiri Olsa Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit 504f9ce3bcfe996a8a0601e5fadbc777603c1cdb Author: Jouni Högander Date: Fri Jun 7 16:49:13 2024 +0300 drm/i915/psr: Print Panel Replay status instead of frame lock status [ Upstream commit 51ee1f29a9aceb8a52037ba4759d44c70e966fe5 ] Currently Panel Replay status printout is printing frame lock status. It should print Panel Replay status instead. Panel Replay status register field follows PSR status register field. Use existing PSR code for that. Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay") Signed-off-by: Jouni Högander Reviewed-by: Animesh Manna Link: https://patchwork.freedesktop.org/patch/msgid/20240607134917.1327574-10-jouni.hogander@intel.com Signed-off-by: Sasha Levin commit 63b0fcbbaaf0c6680840bfebb7fa31d153b57270 Author: Jouni Högander Date: Fri Jun 7 16:49:08 2024 +0300 drm/i915/display: Skip Panel Replay on pipe comparison if no active planes [ Upstream commit 955446ed6e822b86751993bd69022d347b43a99e ] Panel Replay is not enabled if there are no active planes. Do not compare it on pipe comparison. Otherwise we get pipe mismatch. Fixes: ac9ef327327b ("drm/i915/psr: Panel replay has to be enabled before link training") Signed-off-by: Jouni Högander Reviewed-by: Animesh Manna Link: https://patchwork.freedesktop.org/patch/msgid/20240607134917.1327574-5-jouni.hogander@intel.com Signed-off-by: Sasha Levin commit 63d71da2b875a3898c149f7d3fb34642f673840e Author: Adam Ford Date: Sat Jun 1 09:41:01 2024 -0500 drm/bridge: samsung-dsim: Set P divider based on min/max of fin pll [ Upstream commit 78c4c0011bb577a29906d8ca135795af2293c49e ] The P divider should be set based on the min and max values of the fin pll which may vary between different platforms. These ranges are defined per platform, but hard-coded values were used instead which resulted in a smaller range available on the i.MX8M[MNP] than what was possible. As noted by Frieder, there are descripencies between the reference manuals of the Mini, Nano and Plus, so I reached out to my NXP rep and got the following response regarding the varing notes in the documentation. "Yes it is definitely wrong, the one that is part of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is not correct. I will report this to Doc team, the one customer should be take into account is the Table 13-40 DPHY PLL Parameters and the Note above." With this patch, the clock rates now match the values used in NXP's downstream kernel. Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock") Signed-off-by: Adam Ford Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Reviewed-by: Marek Vasut Tested-by: Marek Szyprowski Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240601144103.198299-1-aford173@gmail.com Signed-off-by: Sasha Levin commit 309fdbb585186e1be19c655f07f7a84818606037 Author: Yunfei Dong Date: Fri Apr 12 11:57:31 2024 +0800 media: mediatek: vcodec: Fix unreasonable data conversion [ Upstream commit 48d85de244047eabe07c5040af12dfa736d61d6c ] Both 'bs_dma' and 'dma_addr' are integers. No need to convert the type from dma_addr_t to uint64_t again. Fixes: d353c3c34af0 ("media: mediatek: vcodec: support 36 bits physical address") Signed-off-by: Yunfei Dong Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cdf05ae76198c513836bde4eb55f099c44773280 Author: Irui Wang Date: Thu Mar 21 09:47:54 2024 +0800 media: mediatek: vcodec: Handle invalid decoder vsi [ Upstream commit 59d438f8e02ca641c58d77e1feffa000ff809e9f ] Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use. Fixes: 590577a4e525 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver") Signed-off-by: Irui Wang Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a59088577033a148b9c5e1beb5c2ff77e2ab06b2 Author: Ian Rogers Date: Tue May 21 09:51:07 2024 -0700 perf maps: Fix use after free in __maps__fixup_overlap_and_insert [ Upstream commit 0b90dfda222e38b7ca8dad6e098e36f5186f0b94 ] In the case 'before' and 'after' are broken out from pos, maps_by_address may be changed by __maps__insert, as such it needs re-reading. Don't ignore the return value from __maps_insert. Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: Ian Rogers Reviewed-by: James Clark Cc: Steinar H . Gunderson Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240521165109.708593-2-irogers@google.com Signed-off-by: Sasha Levin commit e1d86efd469865fac64f64b6ede4d64ad69043ed Author: Dmitry Baryshkov Date: Tue Feb 27 00:34:45 2024 +0200 drm/msm/dp: fix runtime_pm handling in dp_wait_hpd_asserted [ Upstream commit aeacc39e2088a15ee31c8af4f68c84981fa08eb7 ] The function dp_wait_hpd_asserted() uses pm_runtime_get_sync() and doesn't care about the return value. Potentially this can lead to unclocked access if for some reason resuming of the DP controller fails. Change the function to use pm_runtime_resume_and_get() and return an error if resume fails. Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Reviewed-by: Stephen Boyd Patchwork: https://patchwork.freedesktop.org/patch/580137/ Link: https://lore.kernel.org/r/20240226223446.4194079-1-dmitry.baryshkov@linaro.org [quic_abhinavk@quicinc.com: resolved trivial conflict while rebase] Signed-off-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 7deaf31e79bb8b36b80b3bf492a1fdc2bff51821 Author: Junhao Xie Date: Fri May 24 23:01:12 2024 +0800 drm/msm/dpu: drop duplicate drm formats from wb2_formats arrays [ Upstream commit 6ed817592638348e83facfe6a4deedb8d5e83357 ] There are duplicate items in wb2_formats_rgb and wb2_formats_rgb_yuv, which cause weston assertions failed. weston: libweston/drm-formats.c:131: weston_drm_format_array_add_format: Assertion `!weston_drm_format_array_find_format(formats, format)' failed. Signed-off-by: Junhao Xie Reviewed-by: Konrad Dybcio Fixes: 8c16b988ba2d ("drm/msm/dpu: introduce separate wb2_format arrays for rgb and yuv") Fixes: 53324b99bd7b ("drm/msm/dpu: add writeback blocks to the sm8250 DPU catalog") Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/596847/ Link: https://lore.kernel.org/r/20240524150128.1878297-2-bigfoot@classfun.cn Signed-off-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ca168c0d8faf16424314f104decc710536c02355 Author: Dmitry Baryshkov Date: Wed May 22 13:24:28 2024 +0300 Revert "drm/msm/dpu: drop dpu_encoder_phys_ops.atomic_mode_set" [ Upstream commit 35322c39a653c775670f0713fb96ccc2cd91a747 ] In the DPU driver blank IRQ handling is called from a vblank worker and can happen outside of the irq_enable / irq_disable pair. Using the worker makes that completely asynchronous with the rest of the code. Revert commit d13f638c9b88 ("drm/msm/dpu: drop dpu_encoder_phys_ops.atomic_mode_set") to fix vblank IRQ assignment for CMD DSI panels. Call trace: dpu_encoder_phys_cmd_control_vblank_irq+0x218/0x294 dpu_encoder_toggle_vblank_for_crtc+0x160/0x194 dpu_crtc_vblank+0xbc/0x228 dpu_kms_enable_vblank+0x18/0x24 vblank_ctrl_worker+0x34/0x6c process_one_work+0x218/0x620 worker_thread+0x1ac/0x37c kthread+0x114/0x118 ret_from_fork+0x10/0x20 Fixes: d13f638c9b88 ("drm/msm/dpu: drop dpu_encoder_phys_ops.atomic_mode_set") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/595065/ Link: https://lore.kernel.org/r/20240522-dpu-revert-ams-v2-1-b37825d708e1@linaro.org Signed-off-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 956bb63a227f4adb63268eaffdfe4239f4d709f8 Author: Barnabás Czémán Date: Thu May 9 21:40:41 2024 +0200 drm/msm/dpu: fix encoder irq wait skip [ Upstream commit e42d518511871ae625b5ff699853a05af1ccccf7 ] The irq_idx is unsigned so it cannot be lower than zero, better to change the condition to check if it is equal with zero. It could not cause any issue because a valid irq index starts from one. Fixes: 5a9d50150c2c ("drm/msm/dpu: shift IRQ indices by 1") Signed-off-by: Barnabás Czémán Reviewed-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/596853/ Link: https://lore.kernel.org/r/20240509-irq_wait-v2-1-b8b687b22cc4@gmail.com Signed-off-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b21aba72aadd94bdac275deab021fc84d6c72b16 Author: David Hildenbrand Date: Wed May 8 20:29:46 2024 +0200 s390/uv: Don't call folio_wait_writeback() without a folio reference [ Upstream commit 3f29f6537f54d74e64bac0a390fb2e26da25800d ] folio_wait_writeback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference. Fixes: 214d9bbcd3a6 ("s390/mm: provide memory management functions for protected KVM guests") Reviewed-by: Claudio Imbrenda Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20240508182955.358628-2-david@redhat.com Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit bd7e3335a8b9cb97854a7368938e9111ff17efb9 Author: Srinivasan Shanmugam Date: Sat May 25 07:39:01 2024 +0530 drm/amdgpu: Fix type mismatch in amdgpu_gfx_kiq_init_ring [ Upstream commit 745f7170db4ffd2f2e9751a2c719a97c9a5fc438 ] This commit fixes a type mismatch in the amdgpu_gfx_kiq_init_ring function triggered by the snprintf function expecting unsigned char arguments due to the '%hhu' format specifier, but receiving int and u32 arguments. The issue occurred because the arguments xcc_id, ring->me, ring->pipe, and ring->queue were of type int and u32, not unsigned char. This led to a type mismatch when these arguments were passed to snprintf. To resolve this, the snprintf line was modified to cast these arguments to unsigned char. This ensures that the arguments are of the correct type for the '%hhu' format specifier and resolves the warning. Fixes the below: >> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:333:4: warning: format >> specifies type 'unsigned char' but the argument has type 'int' >> [-Wformat] xcc_id, ring->me, ring->pipe, ring->queue); ^~~~~~ >> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:333:12: warning: format >> specifies type 'unsigned char' but the argument has type 'u32' (aka >> 'unsigned int') [-Wformat] xcc_id, ring->me, ring->pipe, ring->queue); ^~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:333:22: warning: format specifies type 'unsigned char' but the argument has type 'u32' (aka 'unsigned int') [-Wformat] xcc_id, ring->me, ring->pipe, ring->queue); ^~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:333:34: warning: format specifies type 'unsigned char' but the argument has type 'u32' (aka 'unsigned int') [-Wformat] xcc_id, ring->me, ring->pipe, ring->queue); ^~~~~~~~~~~ 4 warnings generated. Fixes: 0ea554455542 ("drm/amdgpu: Fix snprintf usage in amdgpu_gfx_kiq_init_ring") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202405250446.XeaWe66u-lkp@intel.com/ Cc: Lijo Lazar Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b87e28050d9b0959de24574d587825cfab2f13fb Author: ChiYuan Huang Date: Wed May 8 10:51:49 2024 +0800 media: v4l: async: Fix NULL pointer dereference in adding ancillary links [ Upstream commit 9b4667ea67854f0b116fe22ad11ef5628c5b5b5f ] In v4l2_async_create_ancillary_links(), ancillary links are created for lens and flash sub-devices. These are sub-device to sub-device links and if the async notifier is related to a V4L2 device, the source sub-device of the ancillary link is NULL, leading to a NULL pointer dereference. Check the notifier's sd field is non-NULL in v4l2_async_create_ancillary_links(). Fixes: aa4faf6eb271 ("media: v4l2-async: Create links during v4l2_async_match_notify()") Signed-off-by: ChiYuan Huang [Sakari Ailus: Reword the subject and commit messages slightly.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 04be7591f31076a02077e1fbc530d85786ad143e Author: Ricardo Ribalda Date: Thu May 9 17:05:55 2024 +0000 media: i2c: hi846: Fix V4L2_SUBDEV_FORMAT_TRY get_selection() [ Upstream commit 984abe0b5794a2aca359bb61555351d2ec520d2a ] The current code does not return anything to the user. Although the code looks a bit dangerous (using a pointer without checking if it is valid), it should be fine. The core validates that sel->pad has a valid value. Fix the following smatch error: drivers/media/i2c/hi846.c:1854 hi846_get_selection() warn: statement has no effect 31 Fixes: e8c0882685f9 ("media: i2c: add driver for the SK Hynix Hi-846 8M pixel camera") Signed-off-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart [Sakari Ailus: code -> core.] Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f843053eca59c3e31e3befb4452edf756149e03d Author: Bryan O'Donoghue Date: Thu May 9 13:53:07 2024 +0100 media: i2c: Fix imx412 exposure control [ Upstream commit a1956bf53a2774014ee1768b484af2c38c633a25 ] Currently we have the following algorithm to calculate what value should be written to the exposure control of imx412. lpfr = imx412->vblank + imx412->cur_mode->height; shutter = lpfr - exposure; The 'shutter' value is given to IMX412_REG_EXPOSURE_CIT however, the above algorithm will result in the value given to IMX412_REG_EXPOSURE_CIT decreasing as the requested exposure value from user-space goes up. e.g. [ 2255.713989] imx412 20-001a: Received exp 1608, analog gain 0 [ 2255.714002] imx412 20-001a: Set exp 1608, analog gain 0, shutter 1938, lpfr 3546 [ 2256.302770] imx412 20-001a: Received exp 2586, analog gain 100 [ 2256.302800] imx412 20-001a: Set exp 2586, analog gain 100, shutter 960, lpfr 3546 [ 2256.753755] imx412 20-001a: Received exp 3524, analog gain 110 [ 2256.753772] imx412 20-001a: Set exp 3524, analog gain 110, shutter 22, lpfr 3546 This behaviour results in the image having less exposure as the requested exposure value from user-space increases. Other sensor drivers such as ov5675, imx218, hid556 and others take the requested exposure value and use the value directly. Take the example of the above cited sensor drivers and directly apply the requested exposure value from user-space. The 'lpfr' variable still functions as before but the 'shutter' variable can be dispensed with as a result. Once done a similar run of the test application requesting higher exposure looks like this, with 'exp' written directly to the sensor. [ 133.207884] imx412 20-001a: Received exp 1608, analog gain 0 [ 133.207899] imx412 20-001a: Set exp 1608, analog gain 0, lpfr 3546 [ 133.905309] imx412 20-001a: Received exp 2844, analog gain 100 [ 133.905344] imx412 20-001a: Set exp 2844, analog gain 100, lpfr 3546 [ 134.241705] imx412 20-001a: Received exp 3524, analog gain 110 [ 134.241775] imx412 20-001a: Set exp 3524, analog gain 110, lpfr 3546 The result is then setting the sensor exposure to lower values results in darker, less exposure images and vice versa with higher exposure values. Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Tested-by: Bryan O'Donoghue # qrb5165-rb5/imx577 Reviewed-by: Jacopo Mondi Reviewed-by: Gjorgji Rosikopulos Signed-off-by: Bryan O'Donoghue Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3d4e5b75e9903ac48b3580c2937f2ce75136736e Author: Jouni Högander Date: Wed May 29 12:38:46 2024 +0300 drm/i915/psr: Use enable boolean from intel_crtc_state for Early Transport [ Upstream commit 0a8c581ce01c84214b8221fcc5d52b45c09d0007 ] When enabling Early Transport use intel_crtc_state->enable_psr2_su_region_et instead of psr2_su_region_et_valid. Reviewed-by: Animesh Manna Fixes: 467e4e061c44 ("drm/i915/psr: Enable psr2 early transport as possible") Signed-off-by: Jouni Högander Link: https://patchwork.freedesktop.org/patch/msgid/20240529093849.1016172-4-jouni.hogander@intel.com Signed-off-by: Sasha Levin commit 6f611b000d623c27e04118c9260af8200c0db8e2 Author: Ricardo Ribalda Date: Mon May 6 21:10:27 2024 +0000 media: imon: Fix race getting ictx->lock [ Upstream commit 24147897507cd3a7d63745d1518a638bf4132238 ] Lets fix a race between mutex_is_lock() and mutex_lock(). <-mutex is not locked if (!mutex_is_locked(&ictx->lock)) { unlock = true; <- mutex is locked externaly mutex_lock(&ictx->lock); } Let's use mutex_trylock() that does mutex_is_lock() and mutex_lock() atomically. Fix the following cocci warning: drivers/media/rc/imon.c:1167:1-7: preceding lock on line 1153 Fixes: 23ef710e1a6c ("[media] imon: add conditional locking in change_protocol") Signed-off-by: Ricardo Ribalda Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit ad24b56e0d987d3eae28e76ba9c11cacecaf0bf1 Author: Zheng Yejian Date: Thu May 9 20:44:14 2024 +0800 media: dvb-usb: Fix unexpected infinite loop in dvb_usb_read_remote_control() [ Upstream commit 2052138b7da52ad5ccaf74f736d00f39a1c9198c ] Infinite log printing occurs during fuzz test: rc rc1: DViCO FusionHDTV DVB-T USB (LGZ201) as ... ... dvb-usb: schedule remote query interval to 100 msecs. dvb-usb: DViCO FusionHDTV DVB-T USB (LGZ201) successfully initialized ... dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) dvb-usb: bulk message failed: -22 (1/0) ... dvb-usb: bulk message failed: -22 (1/0) Looking into the codes, there is a loop in dvb_usb_read_remote_control(), that is in rc_core_dvb_usb_remote_init() create a work that will call dvb_usb_read_remote_control(), and this work will reschedule itself at 'rc_interval' intervals to recursively call dvb_usb_read_remote_control(), see following code snippet: rc_core_dvb_usb_remote_init() { ... INIT_DELAYED_WORK(&d->rc_query_work, dvb_usb_read_remote_control); schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); ... } dvb_usb_read_remote_control() { ... err = d->props.rc.core.rc_query(d); if (err) err(...) // Did not return even if query failed schedule_delayed_work(&d->rc_query_work, msecs_to_jiffies(rc_interval)); } When the infinite log printing occurs, the query callback 'd->props.rc.core.rc_query' is cxusb_rc_query(). And the log is due to the failure of finding a valid 'generic_bulk_ctrl_endpoint' in usb_bulk_msg(), see following code snippet: cxusb_rc_query() { cxusb_ctrl_msg() { dvb_usb_generic_rw() { ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint),...); if (ret) err("bulk message failed: %d (%d/%d)",ret,wlen,actlen); ... } ... } By analyzing the corresponding USB descriptor, it shows that the bNumEndpoints is 0 in its interface descriptor, but the 'generic_bulk_ctrl_endpoint' is 1, that means user don't configure a valid endpoint for 'generic_bulk_ctrl_endpoint', therefore this 'invalid' USB device should be rejected before it calls into dvb_usb_read_remote_control(). To fix it, we need to add endpoint check for 'generic_bulk_ctrl_endpoint'. And as Sean suggested, the same check and clear halts should be done for 'generic_bulk_ctrl_endpoint_response'. So introduce dvb_usb_check_bulk_endpoint() to do it for both of them. Fixes: 4d43e13f723e ("V4L/DVB (4643): Multi-input patch for DVB-USB device") Signed-off-by: Zheng Yejian Signed-off-by: Sean Young Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c766065e8272085ea9c436414b7ddf1f12e7787b Author: Mikhail Kobuk Date: Thu Mar 28 02:32:23 2024 +0300 media: pci: ivtv: Add check for DMA map result [ Upstream commit 629913d6d79508b166c66e07e4857e20233d85a9 ] In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1932dc2f4cf6 ("media: pci/ivtv: switch from 'pci_' to 'dma_' API") Signed-off-by: Mikhail Kobuk Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0afb3c7020844c8604a7dda0b1898148e6a961a7 Author: Arnd Bergmann Date: Tue May 28 13:51:21 2024 +0200 drm/amd/display: Move 'struct scaler_data' off stack [ Upstream commit f8718c482572181ca364ffca3c27365cc83cfe9e ] The scaler_data structure is implicitly copied onto the stack twice by being returned from a function. This is usually a bad idea, but it was not flagged by the compiler until a recent addition that pushed it over the 1024 byte function stack limit: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_translation_helper.c: In function 'populate_dml_plane_cfg_from_plane_state': drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_translation_helper.c:1075:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Use an explicit kzalloc() and memcpy() instead here to keep it off the stack. Fixes: 00c391102abc ("drm/amd/display: Add misc DC changes for DCN401") Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2") Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a9b68a2f325e4cf81e9cb614fd0087a710282190 Author: Arnd Bergmann Date: Tue May 28 13:51:19 2024 +0200 drm/amd/display: fix graphics_object_id size [ Upstream commit 6d438caaeaa1a7fae7b523e7bc4cee262b9f101a ] The graphics_object_id structure is meant to fit into 32 bits, as it's passed by value in and out of functions. A recent change increased the size to 128 bits, so it's now always passed by reference, which is clearly not intended and ends up producing a compile-time warning: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c: In function 'construct_phy': drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:743:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Add back the bitfields to revert to the original size, while keeping the 'enum' type change. Fixes: fec85f995a4b ("drm/amd/display: Fix compiler redefinition warnings for certain configs") Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 814d1469dd35c77e1148ea225c68828ea3362792 Author: Arnd Bergmann Date: Tue May 28 13:51:18 2024 +0200 drm/amd/display: dynamically allocate dml2_configuration_options structures [ Upstream commit 88c61827cedc14cd305d4266dc18ff0fdb3f8d4c ] This structure is too large to fit on a stack, as shown by the newly introduced warnings from a recent code change: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c: In function 'dcn32_update_bw_bounding_box': drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2019:1: error: the frame size of 1180 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c: In function 'dcn321_update_bw_bounding_box': drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn321/dcn321_resource.c:1597:1: error: the frame size of 1180 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c: In function 'dc_state_create': drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_state.c:219:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Instead of open-coding the assignment of a large structure to a stack variable, use an explicit kmemdup() in each case to move it off the stack. Fixes: e779f4587f61 ("drm/amd/display: Add handling for DC power mode") Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 79161e9cc12a782112af0d50c8fc9948614facfd Author: Srinivasan Shanmugam Date: Tue May 21 10:03:37 2024 +0530 drm/amdgpu: Fix snprintf usage in amdgpu_gfx_kiq_init_ring [ Upstream commit 0ea55445554209913a72eab86b60f5788776c4d6 ] This commit fixes a format truncation issue arosed by the snprintf function potentially writing more characters into the ring->name buffer than it can hold, in the amdgpu_gfx_kiq_init_ring function The issue occurred because the '%d' format specifier could write between 1 and 10 bytes into a region of size between 0 and 8, depending on the values of xcc_id, ring->me, ring->pipe, and ring->queue. The snprintf function could output between 12 and 41 bytes into a destination of size 16, leading to potential truncation. To resolve this, the snprintf line was modified to use the '%hhu' format specifier for xcc_id, ring->me, ring->pipe, and ring->queue. The '%hhu' specifier is used for unsigned char variables and ensures that these values are printed as unsigned decimal integers. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c: In function ‘amdgpu_gfx_kiq_init_ring’: drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:61: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size between 0 and 8 [-Wformat-truncation=] 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d", | ^~ drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:50: note: directive argument in the range [0, 2147483647] 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d", | ^~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:332:9: note: ‘snprintf’ output between 12 and 41 bytes into a destination of size 16 332 | snprintf(ring->name, sizeof(ring->name), "kiq_%d.%d.%d.%d", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 333 | xcc_id, ring->me, ring->pipe, ring->queue); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 345a36c4f1ba ("drm/amdgpu: prefer snprintf over sprintf") Cc: Alex Deucher Cc: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8607894112f1d215a9f44bfa0f67e8c26af429f9 Author: Kuro Chung Date: Wed May 22 14:55:28 2024 +0800 drm/bridge: it6505: fix hibernate to resume no display issue [ Upstream commit 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005 ] When the system power resumes, the TTL input of IT6505 may experience some noise before the video signal stabilizes, necessitating a video reset. This patch is implemented to prevent a loop of video error interrupts, which can occur when a video reset in the video FIFO error interrupt triggers another such interrupt. The patch processes the SCDT and FIFO error interrupts simultaneously and ignores any video FIFO error interrupts caused by a video reset. Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Kuro Chung Signed-off-by: Hermes Wu Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240522065528.1053439-1-kuro.chung@ite.com.tw Signed-off-by: Sasha Levin commit c47583f3cb0669f5a553f8a7ec7adcc7fb794d32 Author: Douglas Anderson Date: Fri May 17 14:36:40 2024 -0700 drm/panel: ilitek-ili9882t: Check for errors on the NOP in prepare() [ Upstream commit 6a7bd6cde73f0fb7e5faa964dbdeb45b55c64698 ] The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in ili9882t_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: e2450d32e5fb ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240517143643.5.I323476ba9fa8cc7a5adee4c1ec95202785cc5686@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.5.I323476ba9fa8cc7a5adee4c1ec95202785cc5686@changeid Signed-off-by: Sasha Levin commit 30c229ef8d2c86321e1bbe19b19ea7e2624d5ef8 Author: Douglas Anderson Date: Fri May 17 14:36:39 2024 -0700 drm/panel: ilitek-ili9882t: If prepare fails, disable GPIO before regulators [ Upstream commit 554c00181968d43426bfe68c86541b89265075de ] The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: e2450d32e5fb ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240517143643.4.Ieb0179065847972a0f13e9a8574a80a5f65f3338@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.4.Ieb0179065847972a0f13e9a8574a80a5f65f3338@changeid Signed-off-by: Sasha Levin commit 505c099de10c6aa60a4e6ae551184e625113a297 Author: Douglas Anderson Date: Fri May 17 14:36:38 2024 -0700 drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare() [ Upstream commit 6320b9199dd99622668649c234d4e8a99e44a9c8 ] The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in boe_panel_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 812562b8d881 ("drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence") Signed-off-by: Douglas Anderson Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Dmitry Baryshkov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid Signed-off-by: Sasha Levin commit 4c34113e9d08c48e22e735ba55dbc374be31b23c Author: Douglas Anderson Date: Fri May 17 14:36:37 2024 -0700 drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before regulators [ Upstream commit 587c48f622374e5d47b1d515c6006a4df4dee882 ] The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid Signed-off-by: Sasha Levin commit 5e42e925ce8d979adc121a80b3c5feb5d4075381 Author: Douglas Anderson Date: Fri May 17 14:36:36 2024 -0700 drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on() better [ Upstream commit cc2db2ef8d9eebc0df03808ac0dadbdb96733499 ] If mipi_dsi_dcs_set_display_on() returned an error then we'd store that in the "ret" variable and jump to error handling. We'd then attempt an orderly poweroff. Unfortunately we then blew away the value stored in "ret". That means that if the orderly poweroff actually worked then we're return 0 (no error) from hx8394_enable() even though the panel wasn't enabled. Fix this by not blowing away "ret". Found by code inspection. Fixes: 65dc9360f741 ("drm: panel: Add Himax HX8394 panel controller driver") Signed-off-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid Signed-off-by: Sasha Levin commit 889f0cb5a83d9bc53fde394872f3108e717c92c2 Author: Tim Van Patten Date: Thu May 16 11:57:25 2024 -0600 drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1 [ Upstream commit 1446226d32a45bb7c4f63195a59be8c08defe658 ] The following commit updated gmc->noretry from 0 to 1 for GC HW IP 9.3.0: commit 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1") This causes the device to hang when a page fault occurs, until the device is rebooted. Instead, revert back to gmc->noretry=0 so the device is still responsive. Fixes: 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1") Signed-off-by: Tim Van Patten Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9084114e338597f8102335e427d08e6af0f3dae0 Author: Friedrich Vock Date: Tue May 14 09:06:38 2024 +0200 drm/amdgpu: Check if NBIO funcs are NULL in amdgpu_device_baco_exit [ Upstream commit 0cdb3f9740844b9d95ca413e3fcff11f81223ecf ] The special case for VM passthrough doesn't check adev->nbio.funcs before dereferencing it. If GPUs that don't have an NBIO block are passed through, this leads to a NULL pointer dereference on startup. Signed-off-by: Friedrich Vock Fixes: 1bece222eabe ("drm/amdgpu: Clear doorbell interrupt status for Sienna Cichlid") Cc: Alex Deucher Cc: Christian König Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 422b081874bbc33837acde539cc1e288cbd0167b Author: Lijo Lazar Date: Fri May 10 13:30:34 2024 +0530 drm/amdgpu: Fix memory range calculation [ Upstream commit ce798376ef6764de51d8f4684ae525b55df295fa ] Consider the 16M reserved region also before range calculation for GMC 9.4.3 SOCs. Fixes: a433f1f59484 ("drm/amdgpu: Initialize memory ranges for GC 9.4.3") Signed-off-by: Lijo Lazar Acked-by: Christian König Reviewed-by: Le Ma Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6369ac0eb0c3bfe1319c553653be8b05f48eb3ce Author: Lijo Lazar Date: Thu May 9 14:14:10 2024 +0530 drm/amd/pm: Fix aldebaran pcie speed reporting [ Upstream commit b6420021e17e262c57bb289d0556ee181b014f9c ] Fix the field definitions for LC_CURRENT_DATA_RATE. Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)") Signed-off-by: Lijo Lazar Reviewed-by: Asad Kamal Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ca503105cbe5785ba8a445a7284052e4c449470c Author: Dmitry Baryshkov Date: Sun May 12 02:00:18 2024 +0300 drm/panel: lg-sw43408: add missing error handling [ Upstream commit 51f9183e4af8c7f00e81180cbb9ee4a98a0f0aa1 ] Add missing error handling for the mipi_dsi_ functions that actually return error code instead of silently ignoring it. Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Douglas Anderson Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240512-dsi-panels-upd-api-v2-1-e31ca14d102e@linaro.org Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240512-dsi-panels-upd-api-v2-1-e31ca14d102e@linaro.org Signed-off-by: Sasha Levin commit 6f793d85289fdbdd95b04c09a5d5836f10d82564 Author: Douglas Anderson Date: Tue May 14 10:20:52 2024 -0700 drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() [ Upstream commit 24acbcce5cc673886c2f4f9b3f6f89a9c6a53b7e ] The mipi_dsi_generic_write_seq() macro makes a call to mipi_dsi_generic_write() which returns a type ssize_t. The macro then stores it in an int and checks to see if it's negative. This could theoretically be a problem if "ssize_t" is larger than "int". To see the issue, imagine that "ssize_t" is 32-bits and "int" is 16-bits, you could see a problem if there was some code out there that looked like: mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>); ...since we'd get back that 32768 bytes were transferred and 32768 stored in a 16-bit int would look negative. Though there are no callsites where we'd actually hit this (even if "int" was only 16-bit), it's cleaner to make the types match so let's fix it. Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro") Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20240514102056.v5.2.Iadb65b8add19ed3ae3ed6425011beb97e380a912@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240514102056.v5.2.Iadb65b8add19ed3ae3ed6425011beb97e380a912@changeid Signed-off-by: Sasha Levin commit 810066677eb8cd951e4bfbda7bac1ed4c52d6e28 Author: Douglas Anderson Date: Tue May 14 10:20:51 2024 -0700 drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() [ Upstream commit 0b03829fdece47beba9ecb7dbcbde4585ee3663e ] The mipi_dsi_dcs_write_seq() macro makes a call to mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro then stores it in an int and checks to see if it's negative. This could theoretically be a problem if "ssize_t" is larger than "int". To see the issue, imagine that "ssize_t" is 32-bits and "int" is 16-bits, you could see a problem if there was some code out there that looked like: mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>); ...since we'd get back that 32768 bytes were transferred and 32768 stored in a 16-bit int would look negative. Though there are no callsites where we'd actually hit this (even if "int" was only 16-bit), it's cleaner to make the types match so let's fix it. Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro") Reviewed-by: Neil Armstrong Reviewed-by: Linus Walleij Signed-off-by: Douglas Anderson Link: https://lore.kernel.org/r/20240514102056.v5.1.I30fa4c8348ea316c886ef8a522a52fed617f930d@changeid Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240514102056.v5.1.I30fa4c8348ea316c886ef8a522a52fed617f930d@changeid Signed-off-by: Sasha Levin commit 1f45e83312b590d799f58b88a2ef32a4702c76f0 Author: Jouni Högander Date: Fri May 10 12:38:13 2024 +0300 drm/i915/display: Do not print "psr: enabled" for on Panel Replay [ Upstream commit d07a578703dbf839ea39bffc425fba2321f45543 ] After setting has_psr for panel replay as well crtc state dump is improperly printing "psr: enabled" for Panel Replay as well. Fix this by checking also has_panel_replay. Fixes: 5afa6e496098 ("drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as well") Signed-off-by: Jouni Högander Reviewed-by: Animesh Manna Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-3-jouni.hogander@intel.com Signed-off-by: Sasha Levin commit f2df0e9cf1c3cb9fd27aa4c0e77e7b828dd22fd1 Author: Jouni Högander Date: Fri May 10 12:38:12 2024 +0300 drm/i915/psr: Rename has_psr2 as has_sel_update [ Upstream commit 1e52db8a439b147f314681129f9ee33f16900767 ] We are going to reuse has_psr2 for panel_replay as well. Rename it as has_sel_update to avoid confusion. v3: do not add has_psr check into psr2 case in intel_dp_compute_vsc_sdp v2: Rebase Signed-off-by: Jouni Högander Reviewed-by: Animesh Manna Link: https://patchwork.freedesktop.org/patch/msgid/20240510093823.3146455-2-jouni.hogander@intel.com Stable-dep-of: d07a578703db ("drm/i915/display: Do not print "psr: enabled" for on Panel Replay") Signed-off-by: Sasha Levin commit e86f34eba0a9af40695ea77320a9537920ac7420 Author: Mukul Joshi Date: Thu May 9 17:29:25 2024 -0400 drm/amdkfd: Fix CU Masking for GFX 9.4.3 [ Upstream commit 85cf43c554e438e2e12b0fe109688c9533e4d93f ] We are incorrectly passing the first XCC's MQD when updating CU masks for other XCCs in the partition. Fix this by passing the MQD for the XCC currently being updated with CU mask to update_cu_mask function. Fixes: fc6efed2c728 ("drm/amdkfd: Update CU masking for GFX 9.4.3") Signed-off-by: Mukul Joshi Reviewed-by: Harish Kasiviswanathan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 23c8257eee9440deadcc5d25bdbee27cdd493030 Author: Faiz Abbas Date: Mon Feb 19 15:39:13 2024 +0530 drm/arm/komeda: Fix komeda probe failing if there are no links in the secondary pipeline [ Upstream commit 9054c46d479b55768adae31031a1afa1b7d62228 ] Since commit 4cfe5cc02e3f ("drm/arm/komeda: Remove component framework and add a simple encoder"), the devm_drm_of_get_bridge() call happens regardless of whether any remote nodes are available on the pipeline. Fix this by moving the bridge attach to its own function and calling it conditional on there being an output link. Fixes: 4cfe5cc02e3f ("drm/arm/komeda: Remove component framework and add a simple encoder") Signed-off-by: Faiz Abbas [Corrected Commit-id of the fixed patch to match mainline] Signed-off-by: Liviu Dudau Acked-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20240219100915.192475-2-faiz.abbas@arm.com Signed-off-by: Sasha Levin commit a97c08513bc334321272fe9fcb9498fd9d962a71 Author: Andy Yan Date: Mon Apr 22 18:19:05 2024 +0800 drm/rockchip: vop2: Fix the port mux of VP2 [ Upstream commit 2bdb481bf7a93c22b9fea8daefa2834aab23a70f ] The port mux of VP2 should be RK3568_OVL_PORT_SET__PORT2_MUX. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan Acked-by: Sascha Hauer Tested-by: Heiko Stuebner Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20240422101905.32703-2-andyshrk@163.com Signed-off-by: Sasha Levin commit e85e7f0936d87dee09ea2d55ce78713bdb6a537a Author: Kuniyuki Iwashima Date: Sun Jul 14 09:17:19 2024 -0700 tcp: Don't access uninit tcp_rsk(req)->ao_keyid in tcp_create_openreq_child(). [ Upstream commit 3f45181358e4df50a40ea1bb51b00a1f295f915e ] syzkaller reported KMSAN splat in tcp_create_openreq_child(). [0] The uninit variable is tcp_rsk(req)->ao_keyid. tcp_rsk(req)->ao_keyid is initialised only when tcp_conn_request() finds a valid TCP AO option in SYN. Then, tcp_rsk(req)->used_tcp_ao is set accordingly. Let's not read tcp_rsk(req)->ao_keyid when tcp_rsk(req)->used_tcp_ao is false. [0]: BUG: KMSAN: uninit-value in tcp_create_openreq_child+0x198b/0x1ff0 net/ipv4/tcp_minisocks.c:610 tcp_create_openreq_child+0x198b/0x1ff0 net/ipv4/tcp_minisocks.c:610 tcp_v4_syn_recv_sock+0x18e/0x2170 net/ipv4/tcp_ipv4.c:1754 tcp_check_req+0x1a3e/0x20c0 net/ipv4/tcp_minisocks.c:852 tcp_v4_rcv+0x26a4/0x53a0 net/ipv4/tcp_ipv4.c:2265 ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline] ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline] ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639 ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674 __netif_receive_skb_list_ptype net/core/dev.c:5703 [inline] __netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751 __netif_receive_skb_list net/core/dev.c:5803 [inline] netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895 gro_normal_list include/net/gro.h:515 [inline] napi_complete_done+0x3f2/0x990 net/core/dev.c:6246 e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808 __napi_poll+0xd9/0x990 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x90f/0x17e0 net/core/dev.c:6962 handle_softirqs+0x152/0x6b0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649 common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278 asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693 __msan_instrument_asm_store+0xd6/0xe0 arch_atomic_inc arch/x86/include/asm/atomic.h:53 [inline] raw_atomic_inc include/linux/atomic/atomic-arch-fallback.h:992 [inline] atomic_inc include/linux/atomic/atomic-instrumented.h:436 [inline] page_ref_inc include/linux/page_ref.h:153 [inline] folio_ref_inc include/linux/page_ref.h:160 [inline] filemap_map_order0_folio mm/filemap.c:3596 [inline] filemap_map_pages+0x11c7/0x2270 mm/filemap.c:3644 do_fault_around mm/memory.c:4879 [inline] do_read_fault mm/memory.c:4912 [inline] do_fault mm/memory.c:5051 [inline] do_pte_missing mm/memory.c:3897 [inline] handle_pte_fault mm/memory.c:5381 [inline] __handle_mm_fault mm/memory.c:5524 [inline] handle_mm_fault+0x3677/0x6f00 mm/memory.c:5689 do_user_addr_fault+0x1373/0x2b20 arch/x86/mm/fault.c:1338 handle_page_fault arch/x86/mm/fault.c:1481 [inline] exc_page_fault+0x54/0xc0 arch/x86/mm/fault.c:1539 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623 Uninit was stored to memory at: tcp_create_openreq_child+0x1984/0x1ff0 net/ipv4/tcp_minisocks.c:611 tcp_v4_syn_recv_sock+0x18e/0x2170 net/ipv4/tcp_ipv4.c:1754 tcp_check_req+0x1a3e/0x20c0 net/ipv4/tcp_minisocks.c:852 tcp_v4_rcv+0x26a4/0x53a0 net/ipv4/tcp_ipv4.c:2265 ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline] ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline] ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639 ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674 __netif_receive_skb_list_ptype net/core/dev.c:5703 [inline] __netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751 __netif_receive_skb_list net/core/dev.c:5803 [inline] netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895 gro_normal_list include/net/gro.h:515 [inline] napi_complete_done+0x3f2/0x990 net/core/dev.c:6246 e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808 __napi_poll+0xd9/0x990 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x90f/0x17e0 net/core/dev.c:6962 handle_softirqs+0x152/0x6b0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649 common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278 asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693 Uninit was created at: __alloc_pages_noprof+0x82d/0xcb0 mm/page_alloc.c:4706 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] alloc_slab_page mm/slub.c:2265 [inline] allocate_slab mm/slub.c:2428 [inline] new_slab+0x2af/0x14e0 mm/slub.c:2481 ___slab_alloc+0xf73/0x3150 mm/slub.c:3667 __slab_alloc mm/slub.c:3757 [inline] __slab_alloc_node mm/slub.c:3810 [inline] slab_alloc_node mm/slub.c:3990 [inline] kmem_cache_alloc_noprof+0x53a/0x9f0 mm/slub.c:4009 reqsk_alloc_noprof net/ipv4/inet_connection_sock.c:920 [inline] inet_reqsk_alloc+0x63/0x700 net/ipv4/inet_connection_sock.c:951 tcp_conn_request+0x339/0x4860 net/ipv4/tcp_input.c:7177 tcp_v4_conn_request+0x13b/0x190 net/ipv4/tcp_ipv4.c:1719 tcp_rcv_state_process+0x2dd/0x4a10 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0xbee/0x10d0 net/ipv4/tcp_ipv4.c:1932 tcp_v4_rcv+0x3fad/0x53a0 net/ipv4/tcp_ipv4.c:2334 ip_protocol_deliver_rcu+0x884/0x1270 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x30f/0x530 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x230/0x4c0 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_sublist_rcv_finish net/ipv4/ip_input.c:580 [inline] ip_list_rcv_finish net/ipv4/ip_input.c:631 [inline] ip_sublist_rcv+0x10f7/0x13e0 net/ipv4/ip_input.c:639 ip_list_rcv+0x952/0x9c0 net/ipv4/ip_input.c:674 __netif_receive_skb_list_ptype net/core/dev.c:5703 [inline] __netif_receive_skb_list_core+0xd92/0x11d0 net/core/dev.c:5751 __netif_receive_skb_list net/core/dev.c:5803 [inline] netif_receive_skb_list_internal+0xd8f/0x1350 net/core/dev.c:5895 gro_normal_list include/net/gro.h:515 [inline] napi_complete_done+0x3f2/0x990 net/core/dev.c:6246 e1000_clean+0x1fa4/0x5e50 drivers/net/ethernet/intel/e1000/e1000_main.c:3808 __napi_poll+0xd9/0x990 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x90f/0x17e0 net/core/dev.c:6962 handle_softirqs+0x152/0x6b0 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu kernel/softirq.c:637 [inline] irq_exit_rcu+0x5d/0x120 kernel/softirq.c:649 common_interrupt+0x83/0x90 arch/x86/kernel/irq.c:278 asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:693 CPU: 0 PID: 239 Comm: modprobe Tainted: G B 6.10.0-rc7-01816-g852e42cc2dd4 #3 1107521f0c7b55c9309062382d0bda9f604dbb6d Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Fixes: 06b22ef29591 ("net/tcp: Wire TCP-AO to request sockets") Reported-by: syzkaller Signed-off-by: Kuniyuki Iwashima Reviewed-by: Eric Dumazet Acked-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://patch.msgid.link/20240714161719.6528-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 70d665b83e2ea3741ac25f347fcf569baa23ea6a Author: Luiz Augusto von Dentz Date: Mon Jul 1 12:07:46 2024 -0400 Bluetooth: Fix usage of __hci_cmd_sync_status [ Upstream commit 87be7b189b2c50d4b51512f59e4e97db4eedee8a ] __hci_cmd_sync_status shall only be used if hci_req_sync_lock is _not_ required which is not the case of hci_dev_cmd so it needs to use hci_cmd_sync_status which uses hci_req_sync_lock internally. Fixes: f1a8f402f13f ("Bluetooth: L2CAP: Fix deadlock") Reported-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f7fb60b5380a8232a9003a3c9f6c9f732829c699 Author: Elliot Ayrey Date: Fri Jul 12 13:31:33 2024 +1200 net: bridge: mst: Check vlan state for egress decision [ Upstream commit 0a1868b93fad5938dbcca77286b25bf211c49f7a ] If a port is blocking in the common instance but forwarding in an MST instance, traffic egressing the bridge will be dropped because the state of the common instance is overriding that of the MST instance. Fix this by skipping the port state check in MST mode to allow checking the vlan state via br_allowed_egress(). This is similar to what happens in br_handle_frame_finish() when checking ingress traffic, which was introduced in the change below. Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Signed-off-by: Elliot Ayrey Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12144069209eec7f2090ce9afa15acdcc2c2a537 Author: Taehee Yoo Date: Fri Jul 12 09:51:16 2024 +0000 xdp: fix invalid wait context of page_pool_destroy() [ Upstream commit 59a931c5b732ca5fc2ca727f5a72aeabaafa85ec ] If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock(). If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2. To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count. If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock(). Splat looks like: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? __wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfx___mutex_lock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? __irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfx___nla_validate_parse+0x10/0x10 ? __pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfx___netdev_update_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? __pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20 To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe. Fixes: c3f812cea0d7 ("page_pool: do not release pool until inflight == 0.") Signed-off-by: Taehee Yoo Reviewed-by: Jakub Kicinski Link: https://patch.msgid.link/20240712095116.3801586-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 468a729b78895893d0e580ceea49bed8ada2a2bd Author: Breno Leitao Date: Fri Jul 12 04:53:25 2024 -0700 virtio_net: Fix napi_skb_cache_put warning [ Upstream commit f8321fa75102246d7415a6af441872f6637c93ab ] After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case. To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context. Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs") Suggested-by: Jakub Kicinski Signed-off-by: Breno Leitao Reviewed-by: Jakub Kicinski Acked-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Heng Qi Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4a0d2efbb773b70fadaad54e33f4796956d850dd Author: Dmitry Antipov Date: Tue Jun 18 21:59:32 2024 +0300 Bluetooth: hci_core, hci_sync: cleanup struct discovery_state [ Upstream commit da63f331353c9e1e6dc29e49e28f8f4fe5d642fd ] After commit 78db544b5d27 ("Bluetooth: hci_core: Remove le_restart_scan work"), 'scan_start' and 'scan_duration' of 'struct discovery_state' are still initialized but actually unused. So remove the aforementioned fields and adjust 'hci_discovery_filter_clear()' and 'le_scan_disable()' accordingly. Compile tested only. Fixes: 78db544b5d27 ("Bluetooth: hci_core: Remove le_restart_scan work") Signed-off-by: Dmitry Antipov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 8424783412074c6948a13147b4de6201694f49c8 Author: Iulia Tanasescu Date: Mon Jun 17 11:52:06 2024 +0300 Bluetooth: hci_event: Set QoS encryption from BIGInfo report [ Upstream commit 5a820b13db3988122080f8de2920721f770c37a0 ] On a Broadcast Sink, after synchronizing to the PA transimitted by a Broadcast Source, the BIGInfo advertising reports emitted by the Controller hold the encryption field, which indicates whether the Broadcast Source is transmitting encrypted streams. This updates the PA sync hcon QoS with the encryption value reported in the BIGInfo report, so that this information is accurate if the userspace tries to access the QoS struct via getsockopt. Fixes: 1d11d70d1f6b ("Bluetooth: ISO: Pass BIG encryption info through QoS") Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit dc14469e43da147840611ffd3bd0aed553a3964a Author: Neeraj Sanjay Kale Date: Fri Jun 14 13:53:38 2024 +0530 Bluetooth: btnxpuart: Add handling for boot-signature timeout errors [ Upstream commit 27489364299a2ddb5c54cd9f29a3f41bd8d151ab ] This handles the timeout error codes sent by the chip as part of the bootloader signatures during firmware download process. When the bootloader does not receive a response packet from the host within a specific time, it adds an error code to the bootloader signature while requesting for the FW chunk from the same offset. The host is expected to clear this error code with a NAK, and reply to only those bootloader signatures which have error code 0. However, the driver was ignoring this error code and replying with the firmware chunks instead, which is apparently ignored by the chip and the chip resends the same bootloader signature with the error code again. This happens in a loop until the error code self clears and firmware download proceeds ahead, adding a couple of milliseconds to the total firmware download time. Commit 689ca16e5232 was an initial implementation which simply printed the following line during driver debug: - FW Download received err 0x04 from chip This commit adds the expected handling to the error codes. This error handling is valid for data_req bootloader signatures for V3 and future bootloader versions. Signed-off-by: Neeraj Sanjay Kale Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit be2ac1f45f39f4f7d11780ad4ab568c8959b308b Author: Kiran K Date: Fri May 17 15:24:46 2024 +0530 Bluetooth: btintel_pcie: Fix irq leak [ Upstream commit 041677e7aad6f57020aa271aafd4cb9e2af1536f ] Free irq before releasing irq vector. Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ea4a294c6feae1e5c41dfe6d3e7d64af011af960 Author: Kiran K Date: Thu May 16 17:54:36 2024 +0530 Bluetooth: btintel: Refactor btintel_set_ppag() [ Upstream commit 0a3e2eca1daa5627c8ecd1554e3146de82d61dd2 ] Current flow iterates the ACPI table associated with Bluetooth controller looking for PPAG method. Method name can be directly passed to acpi_evaluate_object function instead of iterating the table. Fixes: c585a92b2f9c ("Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG)") Signed-off-by: Kiran K Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cfd70400a3115defcb0623255fc0a6e6143a1f47 Author: Sven Peter Date: Wed May 15 18:15:02 2024 +0000 Bluetooth: hci_bcm4377: Use correct unit for timeouts [ Upstream commit 56c695a823e4ee1e5294a8340d5afe5de73828ec ] BCM4377_TIMEOUT is always used to wait for completitions and their API expects a timeout in jiffies instead of msecs. Fixes: 8a06127602de ("Bluetooth: hci_bcm4377: Add new driver for BCM4377 PCIe boards") Signed-off-by: Sven Peter Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit cad797ceeeb191fb6f3ad1ae8859d02afdc89a8c Author: Amit Cohen Date: Thu Jul 11 17:27:02 2024 +0200 selftests: forwarding: devlink_lib: Wait for udev events after reloading [ Upstream commit f67a90a0c8f5b3d0acc18f10650d90fec44775f9 ] Lately, an additional locking was added by commit c0a40097f0bc ("drivers: core: synchronize really_probe() and dev_uevent()"). The locking protects dev_uevent() calling. This function is used to send messages from the kernel to user space. Uevent messages notify user space about changes in device states, such as when a device is added, removed, or changed. These messages are used by udev (or other similar user-space tools) to apply device-specific rules. After reloading devlink instance, udev events should be processed. This locking causes a short delay of udev events handling. One example for useful udev rule is renaming ports. 'forwading.config' can be configured to use names after udev rules are applied. Some tests run devlink_reload() and immediately use the updated names. This worked before the above mentioned commit was pushed, but now the delay of uevent messages causes that devlink_reload() returns before udev events are handled and tests fail. Adjust devlink_reload() to not assume that udev events are already processed when devlink reload is done, instead, wait for udev events to ensure they are processed before returning from the function. Without this patch: TESTS='rif_mac_profile' ./resource_scale.sh TEST: 'rif_mac_profile' 4 [ OK ] sysctl: cannot stat /proc/sys/net/ipv6/conf/swp1/disable_ipv6: No such file or directory sysctl: cannot stat /proc/sys/net/ipv6/conf/swp1/disable_ipv6: No such file or directory sysctl: cannot stat /proc/sys/net/ipv6/conf/swp2/disable_ipv6: No such file or directory sysctl: cannot stat /proc/sys/net/ipv6/conf/swp2/disable_ipv6: No such file or directory Cannot find device "swp1" Cannot find device "swp2" TEST: setup_wait_dev (: Interface swp1 does not come up.) [FAIL] With this patch: $ TESTS='rif_mac_profile' ./resource_scale.sh TEST: 'rif_mac_profile' 4 [ OK ] TEST: 'rif_mac_profile' overflow 5 [ OK ] This is relevant not only for this test. Fixes: bc7cbb1e9f4c ("selftests: forwarding: Add devlink_lib.sh") Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Link: https://patch.msgid.link/89367666e04b38a8993027f1526801ca327ab96a.1720709333.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e187690b125a297499eadeec53c32c5ed6d7436a Author: Kory Maincent Date: Thu Jul 11 15:55:19 2024 +0200 net: ethtool: pse-pd: Fix possible null-deref [ Upstream commit 4cddb0f15ea9c62f81b4889ea69a99368cc63a86 ] Fix a possible null dereference when a PSE supports both c33 and PoDL, but only one of the netlink attributes is specified. The c33 or PoDL PSE capabilities are already validated in the ethnl_set_pse_validate() call. Signed-off-by: Kory Maincent Reported-by: Jakub Kicinski Closes: https://lore.kernel.org/netdev/20240705184116.13d8235a@kernel.org/ Fixes: 4d18e3ddf427 ("net: ethtool: pse-pd: Expand pse commands with the PSE PoE interface") Link: https://patch.msgid.link/20240711-fix_pse_pd_deref-v3-2-edd78fc4fe42@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dd5a33e0af6fdfc4170509be5f01486c116751bb Author: Kory Maincent Date: Thu Jul 11 15:55:18 2024 +0200 net: pse-pd: Do not return EOPNOSUPP if config is null [ Upstream commit 93c3a96c301f0b1ac0bafb5e74bef58e79937648 ] For a PSE supporting both c33 and PoDL, setting config for one type of PoE leaves the other type's config null. Currently, this case returns EOPNOTSUPP, which is incorrect. Instead, we should do nothing if the configuration is empty. Signed-off-by: Kory Maincent Fixes: d83e13761d5b ("net: pse-pd: Use regulator framework within PSE framework") Link: https://patch.msgid.link/20240711-fix_pse_pd_deref-v3-1-edd78fc4fe42@bootlin.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b29a880bb145e1f1c1df5ab88ed26b1495ff9f09 Author: Tengda Wu Date: Thu Jul 11 22:58:18 2024 +0800 bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT [ Upstream commit f7866c35873377313ff94398f17d425b28b71de1 ] When loading a EXT program without specifying `attr->attach_prog_fd`, the `prog->aux->dst_prog` will be null. At this time, calling resolve_prog_type() anywhere will result in a null pointer dereference. Example stack trace: [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 8.108262] Mem abort info: [ 8.108384] ESR = 0x0000000096000004 [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.108722] SET = 0, FnV = 0 [ 8.108827] EA = 0, S1PTW = 0 [ 8.108939] FSC = 0x04: level 0 translation fault [ 8.109102] Data abort info: [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000 [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000 [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 8.112783] Modules linked in: [ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1 [ 8.113230] Hardware name: linux,dummy-virt (DT) [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0 [ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8 [ 8.113798] sp : ffff80008283b9f0 [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4 [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000 [ 8.114126] Call trace: [ 8.114159] may_access_direct_pkt_data+0x24/0xa0 [ 8.114202] bpf_check+0x3bc/0x28c0 [ 8.114214] bpf_prog_load+0x658/0xa58 [ 8.114227] __sys_bpf+0xc50/0x2250 [ 8.114240] __arm64_sys_bpf+0x28/0x40 [ 8.114254] invoke_syscall.constprop.0+0x54/0xf0 [ 8.114273] do_el0_svc+0x4c/0xd8 [ 8.114289] el0_svc+0x3c/0x140 [ 8.114305] el0t_64_sync_handler+0x134/0x150 [ 8.114331] el0t_64_sync+0x168/0x170 [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403) [ 8.118672] ---[ end trace 0000000000000000 ]--- One way to fix it is by forcing `attach_prog_fd` non-empty when bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type` API broken which use verifier log to probe prog type and will log nothing if we reject invalid EXT prog before bpf_check(). Another way is by adding null check in resolve_prog_type(). The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wanted to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows the logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type; It implies that when EXT program is not yet attached to `dst_prog`, the prog type should be EXT itself. This code worked fine in the past. So just keep using it. Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog` is not present in resolve_prog_type(). Fixes: 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") Signed-off-by: Tengda Wu Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Cc: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20240711145819.254178-2-wutengda@huaweicloud.com Signed-off-by: Sasha Levin commit 4799e4e51fe4fac66835d3dfc4f2c56a5123924b Author: Jeff Layton Date: Fri Jul 12 07:26:44 2024 -0400 nfsd: nfsd_file_lease_notifier_call gets a file_lease as an argument [ Upstream commit 769d20028f45a4f442cfe558a32faba357a7f5e2 ] "data" actually refers to a file_lease and not a file_lock. Both structs have their file_lock_core as the first field though, so this bug should be harmless without struct randomization in play. Reported-by: Florian Evers Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219008 Fixes: 05580bbfc6bc ("nfsd: adapt to breakup of struct file_lock") Signed-off-by: Jeff Layton Tested-by: Florian Evers Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 345652866a8869825a2a582ee5a28d75141f184a Author: Shung-Hsi Yu Date: Fri Jul 12 16:01:24 2024 +0800 bpf: fix overflow check in adjust_jmp_off() [ Upstream commit 4a04b4f0de59dd5c621e78f15803ee0b0544eeb8 ] adjust_jmp_off() incorrectly used the insn->imm field for all overflow check, which is incorrect as that should only be done or the BPF_JMP32 | BPF_JA case, not the general jump instruction case. Fix it by using insn->off for overflow check in the general case. Fixes: 5337ac4c9b80 ("bpf: Fix the corner case with may_goto and jump to the 1st insn.") Signed-off-by: Shung-Hsi Yu Link: https://lore.kernel.org/r/20240712080127.136608-2-shung-hsi.yu@suse.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fbb84b1b05c97b5363d916f4c8d1c2797c6f7da2 Author: Alan Maguire Date: Fri Jul 12 10:28:59 2024 +0100 bpf: Eliminate remaining "make W=1" warnings in kernel/bpf/btf.o [ Upstream commit 2454075f8e2915cebbe52a1195631bc7efe2b7e1 ] As reported by Mirsad [1] we still see format warnings in kernel/bpf/btf.o at W=1 warning level: CC kernel/bpf/btf.o ./kernel/bpf/btf.c: In function ‘btf_type_seq_show_flags’: ./kernel/bpf/btf.c:7553:21: warning: assignment left-hand side might be a candidate for a format attribute [-Wsuggest-attribute=format] 7553 | sseq.showfn = btf_seq_show; | ^ ./kernel/bpf/btf.c: In function ‘btf_type_snprintf_show’: ./kernel/bpf/btf.c:7604:31: warning: assignment left-hand side might be a candidate for a format attribute [-Wsuggest-attribute=format] 7604 | ssnprintf.show.showfn = btf_snprintf_show; | ^ Combined with CONFIG_WERROR=y these can halt the build. The fix (annotating the structure field with __printf()) suggested by Mirsad resolves these. Apologies I missed this last time. No other W=1 warnings were observed in kernel/bpf after this fix. [1] https://lore.kernel.org/bpf/92c9d047-f058-400c-9c7d-81d4dc1ef71b@gmail.com/ Fixes: b3470da314fd ("bpf: annotate BTF show functions with __printf") Reported-by: Mirsad Todorovac Suggested-by: Mirsad Todorovac Signed-off-by: Alan Maguire Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240712092859.1390960-1-alan.maguire@oracle.com Signed-off-by: Sasha Levin commit e0f48f51d55fb187400e9787192eda09fa200ff5 Author: Alexey Kodanev Date: Mon Jul 8 10:50:08 2024 +0000 bna: adjust 'name' buf size of bna_tcb and bna_ccb structures [ Upstream commit c9741a03dc8e491e57b95fba0058ab46b7e506da ] To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. Fixes: 8b230ed8ec96 ("bna: Brocade 10Gb Ethernet device driver") Signed-off-by: Alexey Kodanev Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 888d1d38bd1f12328f22151d161b3b8b53a6a74c Author: Alan Maguire Date: Thu Jul 11 19:23:21 2024 +0100 bpf: annotate BTF show functions with __printf [ Upstream commit b3470da314fd8018ee237e382000c4154a942420 ] -Werror=suggest-attribute=format warns about two functions in kernel/bpf/btf.c [1]; add __printf() annotations to silence these warnings since for CONFIG_WERROR=y they will trigger build failures. [1] https://lore.kernel.org/bpf/a8b20c72-6631-4404-9e1f-0410642d7d20@gmail.com/ Fixes: 31d0bc81637d ("bpf: Move to generic BTF show support, apply it to seq files/strings") Reported-by: Mirsad Todorovac Signed-off-by: Alan Maguire Tested-by: Mirsad Todorovac Link: https://lore.kernel.org/r/20240711182321.963667-1-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit a8d0ea2607132dc70126d8c56d50c81f80cefa73 Author: Ilpo Järvinen Date: Mon Jun 10 18:14:42 2024 +0300 selftests/resctrl: Fix closing IMC fds on error and open-code R+W instead of loops [ Upstream commit c44000b6535dc9806b9128d1aed403862b2adab9 ] The imc perf fd close() calls are missing from all error paths. In addition, get_mem_bw_imc() handles fds in a for loop but close() is based on two fixed indexes READ and WRITE. Open code inner for loops to READ+WRITE entries for clarity and add a function to close() IMC fds properly in all cases. Fixes: 7f4d257e3a2a ("selftests/resctrl: Add callback to start a benchmark") Suggested-by: Reinette Chatre Signed-off-by: Ilpo Järvinen Tested-by: Babu Moger Reviewed-by: Reinette Chatre Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6d218fcc707d6b2c3616b6cd24b948fd4825cfec Author: Puranjay Mohan Date: Thu Jul 11 15:18:38 2024 +0000 bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG [ Upstream commit 19d3c179a37730caf600a97fed3794feac2b197b ] When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them the struct bpf_tramp_image *im pointer as an argument in R0. The trampoline generation code uses emit_addr_mov_i64() to emit instructions for moving the bpf_tramp_image address into R0, but emit_addr_mov_i64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpf_tramp_image is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to __bpf_tramp_enter/exit() causing a kernel crash. Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64() as it can work with addresses that are greater than 48-bits. Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64") Signed-off-by: Puranjay Mohan Signed-off-by: Daniel Borkmann Closes: https://lore.kernel.org/all/SJ0PR15MB461564D3F7E7A763498CA6A8CBDB2@SJ0PR15MB4615.namprd15.prod.outlook.com/ Link: https://lore.kernel.org/bpf/20240711151838.43469-1-puranjay@kernel.org Signed-off-by: Sasha Levin commit 5b0889291029602cbb69bfc16997a5a69fb7905d Author: Geliang Tang Date: Wed Jul 10 21:10:17 2024 +0800 selftests/bpf: Close obj in error path in xdp_adjust_tail [ Upstream commit 52b49ec1b2c78deb258596c3b231201445ef5380 ] If bpf_object__load() fails in test_xdp_adjust_frags_tail_grow(), "obj" opened before this should be closed. So use "goto out" to close it instead of using "return" here. Fixes: 110221081aac ("bpf: selftests: update xdp_adjust_tail selftest to include xdp frags") Signed-off-by: Geliang Tang Link: https://lore.kernel.org/r/f282a1ed2d0e3fb38cceefec8e81cabb69cab260.1720615848.git.tanggeliang@kylinos.cn Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 8262bca056784581a56049c1b8b4b9c58112bfda Author: Geliang Tang Date: Wed Jul 10 21:10:16 2024 +0800 selftests/bpf: Null checks for links in bpf_tcp_ca [ Upstream commit eef0532e900c20a6760da829e82dac3ee18688c5 ] Run bpf_tcp_ca selftests (./test_progs -t bpf_tcp_ca) on a Loongarch platform, some "Segmentation fault" errors occur: ''' test_dctcp:PASS:bpf_dctcp__open_and_load 0 nsec test_dctcp:FAIL:bpf_map__attach_struct_ops unexpected error: -524 #29/1 bpf_tcp_ca/dctcp:FAIL test_cubic:PASS:bpf_cubic__open_and_load 0 nsec test_cubic:FAIL:bpf_map__attach_struct_ops unexpected error: -524 #29/2 bpf_tcp_ca/cubic:FAIL test_dctcp_fallback:PASS:dctcp_skel 0 nsec test_dctcp_fallback:PASS:bpf_dctcp__load 0 nsec test_dctcp_fallback:FAIL:dctcp link unexpected error: -524 #29/4 bpf_tcp_ca/dctcp_fallback:FAIL test_write_sk_pacing:PASS:open_and_load 0 nsec test_write_sk_pacing:FAIL:attach_struct_ops unexpected error: -524 #29/6 bpf_tcp_ca/write_sk_pacing:FAIL test_update_ca:PASS:open 0 nsec test_update_ca:FAIL:attach_struct_ops unexpected error: -524 settcpca:FAIL:setsockopt unexpected setsockopt: \ actual -1 == expected -1 (network_helpers.c:99: errno: No such file or directory) \ Failed to call post_socket_cb start_test:FAIL:start_server_str unexpected start_server_str: \ actual -1 == expected -1 test_update_ca:FAIL:ca1_ca1_cnt unexpected ca1_ca1_cnt: \ actual 0 <= expected 0 #29/9 bpf_tcp_ca/update_ca:FAIL #29 bpf_tcp_ca:FAIL Caught signal #11! Stack trace: ./test_progs(crash_handler+0x28)[0x5555567ed91c] linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x7ffffee408b0] ./test_progs(bpf_link__update_map+0x80)[0x555556824a78] ./test_progs(+0x94d68)[0x5555564c4d68] ./test_progs(test_bpf_tcp_ca+0xe8)[0x5555564c6a88] ./test_progs(+0x3bde54)[0x5555567ede54] ./test_progs(main+0x61c)[0x5555567efd54] /usr/lib64/libc.so.6(+0x22208)[0x7ffff2aaa208] /usr/lib64/libc.so.6(__libc_start_main+0xac)[0x7ffff2aaa30c] ./test_progs(_start+0x48)[0x55555646bca8] Segmentation fault ''' This is because BPF trampoline is not implemented on Loongarch yet, "link" returned by bpf_map__attach_struct_ops() is NULL. test_progs crashs when this NULL link passes to bpf_link__update_map(). This patch adds NULL checks for all links in bpf_tcp_ca to fix these errors. If "link" is NULL, goto the newly added label "out" to destroy the skel. v2: - use "goto out" instead of "return" as Eduard suggested. Fixes: 06da9f3bd641 ("selftests/bpf: Test switching TCP Congestion Control algorithms.") Signed-off-by: Geliang Tang Reviewed-by: Alan Maguire Link: https://lore.kernel.org/r/b4c841492bd4ed97964e4e61e92827ce51bf1dc9.1720615848.git.tanggeliang@kylinos.cn Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 72607d8ad89b454dc11315976f0ad7da928bf380 Author: Geliang Tang Date: Tue Jul 9 17:16:19 2024 +0800 selftests/bpf: Close fd in error path in drop_on_reuseport [ Upstream commit adae187ebedcd95d02f045bc37dfecfd5b29434b ] In the error path when update_lookup_map() fails in drop_on_reuseport in prog_tests/sk_lookup.c, "server1", the fd of server 1, should be closed. This patch fixes this by using "goto close_srv1" lable instead of "detach" to close "server1" in this case. Fixes: 0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point") Acked-by: Eduard Zingerman Signed-off-by: Geliang Tang Link: https://lore.kernel.org/r/86aed33b4b0ea3f04497c757845cff7e8e621a2d.1720515893.git.tanggeliang@kylinos.cn Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 29ca547e875014a0d1bdbaec9172fbb6ab86cf2b Author: John Stultz Date: Mon Jul 8 23:08:27 2024 -0700 locking/rwsem: Add __always_inline annotation to __down_write_common() and inlined callers [ Upstream commit e81859fe64ad42dccefe134d1696e0635f78d763 ] Apparently despite it being marked inline, the compiler may not inline __down_write_common() which makes it difficult to identify the cause of lock contention, as the wchan of the blocked function will always be listed as __down_write_common(). So add __always_inline annotation to the common function (as well as the inlined helper callers) to force it to be inlined so a more useful blocking function will be listed (via wchan). This mirrors commit 92cc5d00a431 ("locking/rwsem: Add __always_inline annotation to __down_read_common() and inlined callers") which did the same for __down_read_common. I sort of worry that I'm playing wack-a-mole here, and talking with compiler people, they tell me inline means nothing, which makes me want to cry a little. So I'm wondering if we need to replace all the inlines with __always_inline, or remove them because either we mean something by it, or not. Fixes: c995e638ccbb ("locking/rwsem: Fold __down_{read,write}*()") Reported-by: Tim Murray Signed-off-by: John Stultz Signed-off-by: Peter Zijlstra (Intel) Acked-by: Waiman Long Link: https://lkml.kernel.org/r/20240709060831.495366-1-jstultz@google.com Signed-off-by: Sasha Levin commit 85a28462f87e689881bd428ecc848a9f6b0239ee Author: Johannes Berg Date: Tue Jul 9 08:34:09 2024 +0200 wifi: virt_wifi: don't use strlen() in const context [ Upstream commit 6e909f489191b365364e9d636dec33b5dfd4e5eb ] Looks like not all compilers allow strlen(constant) as a constant, so don't do that. Instead, revert back to defining the length as the first submission had it. Fixes: b5d14b0c6716 ("wifi: virt_wifi: avoid reporting connection success with wrong SSID") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202407090934.NnR1TUbW-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202407090944.mpwLHGt9-lkp@intel.com/ Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c1cb824e662365c27c1d6cb1ecdf487eabd5c08b Author: Johannes Berg Date: Fri Jul 5 13:42:06 2024 +0200 net: page_pool: fix warning code [ Upstream commit 946b6c48cca48591fb495508c5dbfade767173d0 ] WARN_ON_ONCE("string") doesn't really do what appears to be intended, so fix that. Signed-off-by: Johannes Berg Fixes: 90de47f020db ("page_pool: fragment API support for 32-bit arch with 64-bit DMA") Link: https://patch.msgid.link/20240705134221.2f4de205caa1.I28496dc0f2ced580282d1fb892048017c4491e21@changeid Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 378003612bc9c57a6a987e11629f8e712253c8c8 Author: Gaosheng Cui Date: Sat Jul 6 14:50:08 2024 +0800 gss_krb5: Fix the error handling path for crypto_sync_skcipher_setkey [ Upstream commit a3123341dc358952ce2bf8067fbdfb7eaadf71bb ] If we fail to call crypto_sync_skcipher_setkey, we should free the memory allocation for cipher, replace err_return with err_free_cipher to free the memory of cipher. Fixes: 4891f2d008e4 ("gss_krb5: import functionality to derive keys into the kernel") Signed-off-by: Gaosheng Cui Reviewed-by: Simon Horman Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 65b97d6f328f9ae4e16b10150324e547b093b72d Author: Chuck Lever Date: Tue Jun 4 11:24:00 2024 -0400 NFSD: Fix nfsdcld warning [ Upstream commit 18a5450684c312e98eb2253f0acf88b3f780af20 ] Since CONFIG_NFSD_LEGACY_CLIENT_TRACKING is a new config option, its initial default setting should have been Y (if we are to follow the common practice of "default Y, wait, default N, wait, remove code"). Paul also suggested adding a clearer remedy action to the warning message. Reported-by: Paul Menzel Message-Id: Fixes: 74fd48739d04 ("nfsd: new Kconfig option for legacy client tracking") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 0faaa5f29e5130610114f8bd055a724c75029edb Author: Benjamin Tissoires Date: Mon Jul 8 11:52:57 2024 +0200 bpf: helpers: fix bpf_wq_set_callback_impl signature [ Upstream commit f56f4d541eab1ae060a46b56dd6ec9130d6e3a98 ] I realized this while having a map containing both a struct bpf_timer and a struct bpf_wq: the third argument provided to the bpf_wq callback is not the struct bpf_wq pointer itself, but the pointer to the value in the map. Which means that the users need to double cast the provided "value" as this is not a struct bpf_wq *. This is a change of API, but there doesn't seem to be much users of bpf_wq right now, so we should be able to go with this right now. Fixes: 81f1d7a583fa ("bpf: wq: add bpf_wq_set_callback_impl") Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20240708-fix-wq-v2-1-667e5c9fbd99@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 416d3c1538df005195721a200b0371d39636e05d Author: En-Wei Wu Date: Fri Jul 5 10:37:56 2024 +0800 wifi: virt_wifi: avoid reporting connection success with wrong SSID [ Upstream commit b5d14b0c6716fad7f0c94ac6e1d6f60a49f985c7 ] When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. Fixes: c7cdba31ed8b ("mac80211-next: rtnetlink wifi simulation device") Reported-by: syzbot+d6eb9cee2885ec06f5e3@syzkaller.appspotmail.com Signed-off-by: En-Wei Wu Link: https://patch.msgid.link/20240705023756.10954-1-en-wei.wu@canonical.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 574c740486169b6a1380facc0bdea663a781db0a Author: Jianbo Liu Date: Mon Jul 8 09:58:12 2024 +0300 xfrm: call xfrm_dev_policy_delete when kill policy [ Upstream commit 89a2aefe4b084686c2ffc1ee939585111ea4fc0f ] xfrm_policy_kill() is called at different places to delete xfrm policy. It will call xfrm_pol_put(). But xfrm_dev_policy_delete() is not called to free the policy offloaded to hardware. The three commits cited here are to handle this issue by calling xfrm_dev_policy_delete() outside xfrm_get_policy(). But they didn't cover all the cases. An example, which is not handled for now, is xfrm_policy_insert(). It is called when XFRM_MSG_UPDPOLICY request is received. Old policy is replaced by new one, but the offloaded policy is not deleted, so driver doesn't have the chance to release hardware resources. To resolve this issue for all cases, move xfrm_dev_policy_delete() into xfrm_policy_kill(), so the offloaded policy can be deleted from hardware when it is called, which avoids hardware resources leakage. Fixes: 919e43fad516 ("xfrm: add an interface to offload policy") Fixes: bf06fcf4be0f ("xfrm: add missed call to delete offloaded policies") Fixes: 982c3aca8bac ("xfrm: delete offloaded policy") Signed-off-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 31d0172a091dc8e025a6e81ce4abb78930447689 Author: Jianbo Liu Date: Mon Jul 8 09:58:11 2024 +0300 xfrm: fix netdev reference count imbalance [ Upstream commit 9199b915e9fad7f5eff6160d24ff6b38e970107d ] In cited commit, netdev_tracker_alloc() is called for the newly allocated xfrm state, but dev_hold() is missed, which causes netdev reference count imbalance, because netdev_put() is called when the state is freed in xfrm_dev_state_free(). Fix the issue by replacing netdev_tracker_alloc() with netdev_hold(). Fixes: f8a70afafc17 ("xfrm: add TX datapath support for IPsec packet offload mode") Signed-off-by: Jianbo Liu Reviewed-by: Cosmin Ratiu Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 96ae4de5bc4c8ba39fd072369398f59495b73f58 Author: Aleksandr Mishin Date: Thu Jul 4 00:05:10 2024 +0300 wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() [ Upstream commit 85099c7ce4f9e64c66aa397cd9a37473637ab891 ] In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Aleksandr Mishin Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240703210510.11089-1-amishin@t-argos.ru Signed-off-by: Sasha Levin commit 3fd761e3cefdc6cde28d8bda44fe77607e93e80b Author: Sandipan Das Date: Wed Jun 26 13:19:42 2024 +0530 perf/x86/amd/uncore: Fix DF and UMC domain identification [ Upstream commit 57e11990f45f89bc29d0f84dd7b13a4e4263eeb2 ] For uncore PMUs, a single context is shared across all CPUs in a domain. The domain can be a CCX, like in the case of the L3 PMU, or a socket, like in the case of DF and UMC PMUs. This information is available via the PMU's cpumask. For contexts shared across a socket, the domain is currently determined from topology_die_id() which is incorrect after the introduction of commit 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf") as it now returns a CCX identifier on Zen 4 and later systems which support CPUID leaf 0x80000026. Use topology_logical_package_id() instead as it always returns a socket identifier irrespective of the availability of CPUID leaf 0x80000026. Fixes: 63edbaa48a57 ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20240626074942.1044818-1-sandipan.das@amd.com Signed-off-by: Sasha Levin commit 381b21a1cf2ad91661c9d3244eb85331834767d9 Author: Sandipan Das Date: Wed Jun 26 13:14:04 2024 +0530 perf/x86/amd/uncore: Avoid PMU registration if counters are unavailable [ Upstream commit f997e208b6c96858a2f6c0855debfbdb9b52f131 ] X86_FEATURE_PERFCTR_NB and X86_FEATURE_PERFCTR_LLC are derived from CPUID leaf 0x80000001 ECX bits 24 and 28 respectively and denote the availability of DF and L3 counters. When these bits are not set, the corresponding PMUs have no counters and hence, should not be registered. Fixes: 07888daa056e ("perf/x86/amd/uncore: Move discovery and registration") Signed-off-by: Sandipan Das Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20240626074404.1044230-1-sandipan.das@amd.com Signed-off-by: Sasha Levin commit 501b077aefc1addb695be729c8831a5fc91fde27 Author: Zhang Rui Date: Fri Jun 28 11:17:56 2024 +0800 perf/x86/intel/cstate: Fix Alderlake/Raptorlake/Meteorlake [ Upstream commit 2c3aedd9db6295619d21e50ad29efda614023bf1 ] For Alderlake, the spec changes after the patch submitted and PC7/PC9 are removed. Raptorlake and Meteorlake, which copy the Alderlake cstate PMU, also don't have PC7/PC9. Remove PC7/PC9 support for Alderlake/Raptorlake/Meteorlake. Fixes: d0ca946bcf84 ("perf/x86/cstate: Add Alder Lake CPU support") Signed-off-by: Zhang Rui Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kan Liang Link: https://lore.kernel.org/r/20240628031758.43103-2-rui.zhang@intel.com Signed-off-by: Sasha Levin commit 9bed6852d3f561ef78f0f3c22d4a5353e7a931ee Author: Adrian Hunter Date: Mon Jun 24 23:11:00 2024 +0300 perf: Fix default aux_watermark calculation [ Upstream commit 43deb76b19663a96ec2189d8f4eb9a9dc2d7623f ] The default aux_watermark is half the AUX area buffer size. In general, on a 64-bit architecture, the AUX area buffer size could be a bigger than fits in a 32-bit type, but the calculation does not allow for that possibility. However the aux_watermark value is recorded in a u32, so should not be more than U32_MAX either. Fix by doing the calculation in a correctly sized type, and limiting the result to U32_MAX. Fixes: d68e6799a5c8 ("perf: Cap allocation order at aux_watermark") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240624201101.60186-7-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit e8bf18de94550d6c774a6473aacfde23aef100f2 Author: Adrian Hunter Date: Mon Jun 24 23:10:59 2024 +0300 perf: Prevent passing zero nr_pages to rb_alloc_aux() [ Upstream commit dbc48c8f41c208082cfa95e973560134489e3309 ] nr_pages is unsigned long but gets passed to rb_alloc_aux() as an int, and is stored as an int. Only power-of-2 values are accepted, so if nr_pages is a 64_bit value, it will be passed to rb_alloc_aux() as zero. That is not ideal because: 1. the value is incorrect 2. rb_alloc_aux() is at risk of misbehaving, although it manages to return -ENOMEM in that case, it is a result of passing zero to get_order() even though the get_order() result is documented to be undefined in that case. Fix by simply validating the maximum supported value in the first place. Use -ENOMEM error code for consistency with the current error code that is returned in that case. Fixes: 45bfb2e50471 ("perf: Add AUX area to ring buffer for raw data streams") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240624201101.60186-6-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit f86f70e332258d15e76bc523bcfb2069f1c5ab33 Author: Adrian Hunter Date: Mon Jun 24 23:10:58 2024 +0300 perf: Fix perf_aux_size() for greater-than 32-bit size [ Upstream commit 3df94a5b1078dfe2b0c03f027d018800faf44c82 ] perf_buffer->aux_nr_pages uses a 32-bit type, so a cast is needed to calculate a 64-bit size. Fixes: 45bfb2e50471 ("perf: Add AUX area to ring buffer for raw data streams") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240624201101.60186-5-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit d483e01df5cb10b440744137a98f66a8e92f6bb1 Author: Adrian Hunter Date: Mon Jun 24 23:10:57 2024 +0300 perf/x86/intel/pt: Fix pt_topa_entry_for_page() address calculation [ Upstream commit 3520b251dcae2b4a27b95cd6f745c54fd658bda5 ] Currently, perf allocates an array of page pointers which is limited in size by MAX_PAGE_ORDER. That in turn limits the maximum Intel PT buffer size to 2GiB. Should that limitation be lifted, the Intel PT driver can support larger sizes, except for one calculation in pt_topa_entry_for_page(), which is limited to 32-bits. Fix pt_topa_entry_for_page() address calculation by adding a cast. Fixes: 39152ee51b77 ("perf/x86/intel/pt: Get rid of reverse lookup table for ToPA") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20240624201101.60186-4-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 0561e6743c6b5b8ef88c741db227f8d4f329d5be Author: Ilya Leoshkevich Date: Tue Jul 2 01:40:19 2024 +0200 bpf: Fix atomic probe zero-extension [ Upstream commit df34ec9db6f521118895f22795da49f2ec01f8cf ] Zero-extending results of atomic probe operations fails with: verifier bug. zext_dst is set, but no reg is defined The problem is that insn_def_regno() handles BPF_ATOMICs, but not BPF_PROBE_ATOMICs. Fix by adding the missing condition. Fixes: d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT") Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240701234304.14336-2-iii@linux.ibm.com Signed-off-by: Sasha Levin commit c3be81545328a22a44becb293c198f4de4f38462 Author: Tao Chen Date: Tue Jul 2 21:11:50 2024 +0800 bpftool: Mount bpffs when pinmaps path not under the bpffs [ Upstream commit da5f8fd1f0d393d5eaaba9ad8c22d1c26bb2bf9b ] As Quentin said [0], BPF map pinning will fail if the pinmaps path is not under the bpffs, like: libbpf: specified path /home/ubuntu/test/sock_ops_map is not on BPF FS Error: failed to pin all maps [0] https://github.com/libbpf/bpftool/issues/146 Fixes: 3767a94b3253 ("bpftool: add pinmaps argument to the load/loadall") Signed-off-by: Tao Chen Signed-off-by: Daniel Borkmann Tested-by: Quentin Monnet Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240702131150.15622-1-chen.dylane@gmail.com Signed-off-by: Sasha Levin commit 3e6a1b1b179abb643ec3560c02bc3082bc92285f Author: Pu Lehui Date: Sat Jun 22 03:04:36 2024 +0000 riscv, bpf: Fix out-of-bounds issue when preparing trampoline image [ Upstream commit 9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9 ] We get the size of the trampoline image during the dry run phase and allocate memory based on that size. The allocated image will then be populated with instructions during the real patch phase. But after commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im` argument is inconsistent in the dry run and real patch phase. This may cause emit_imm in RV64 to generate a different number of instructions when generating the 'im' address, potentially causing out-of-bounds issues. Let's emit the maximum number of instructions for the "im" address during dry run to fix this problem. Fixes: 26ef208c209a ("bpf: Use arch_bpf_trampoline_size") Signed-off-by: Pu Lehui Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240622030437.3973492-3-pulehui@huaweicloud.com Signed-off-by: Sasha Levin commit 7276b1d7b1e79e0f38c22545409dee053f402da7 Author: Steffen Klassert Date: Fri Jun 28 10:46:25 2024 +0200 xfrm: Export symbol xfrm_dev_state_delete. [ Upstream commit 2d5317753e5f02a66e6d0afb9b25105d0beab1be ] This fixes a build failure if xfrm_user is build as a module. Fixes: 07b87f9eea0c ("xfrm: Fix unregister netdevice hang on hardware offload.") Reported-by: Mark Brown Tested-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 48ec0d5910248ee47814903d1667baf454ea9dcb Author: Martin Kaistra Date: Mon Jun 24 16:00:37 2024 +0200 wifi: rtl8xxxu: 8188f: Limit TX power index [ Upstream commit d0b4b8ef083ca46d5d318e66a30fb80e0abbb90d ] TX power index is read from the efuse on init, the values get written to the TX power registers when the channel gets switched. When the chip has not yet been calibrated, the efuse values are 0xFF, which on some boards leads to USB timeouts for reading/writing registers after the first frames have been sent. The vendor driver (v5.11.5-1) checks for these invalid values and sets default values instead. Implement something similar in rtl8188fu_parse_efuse(). Fixes: c888183b21f3 ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by: Martin Kaistra Reviewed-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240624140037.231657-1-martin.kaistra@linutronix.de Signed-off-by: Sasha Levin commit 74e17a9237196735ad8aa670eed21fb2d29eb8c9 Author: Kuan-Chung Chen Date: Fri Jun 21 20:36:17 2024 +0800 wifi: rtw89: 8852b: fix definition of KIP register number [ Upstream commit 2f35712ab82683554c660bc2456f05785835efbe ] An incorrect definition caused DPK to fail to backup and restore a set of KIP registers. Fixing this will improve RX throughput from 902 to 997 Mbps. Fixes: 5b8471ace5b1 ("wifi: rtw89: 8852b: rfk: add DPK") Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240621123617.6687-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit ef0d9d2f0dc1133db3d3a1c5167190c6627146b2 Author: Chih-Kang Chang Date: Thu Jun 20 13:58:22 2024 +0800 wifi: rtw89: wow: fix GTK offload H2C skbuff issue [ Upstream commit dda364c345913fe03ddbe4d5ae14a2754c100296 ] We mistakenly put skb too large and that may exceed skb->end. Therefore, we fix it. skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev: ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e Hardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021 Workqueue: events_unbound async_run_entry_fn RIP: 0010:skb_panic+0x5d/0x60 Code: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 RSP: 0018:ffffaa700144bad0 EFLAGS: 00010282 RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920 R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010 R13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? skb_panic+0x5d/0x60 ? do_error_trap+0x6d/0x90 ? skb_panic+0x5d/0x60 ? handle_invalid_op+0x30/0x40 ? skb_panic+0x5d/0x60 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_panic+0x5d/0x60 skb_put+0x49/0x50 rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] rtw89_wow_resume+0x31f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] ieee80211_reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] dpm_run_callback+0x3c/0x140 device_resume+0x1f9/0x3c0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 process_scheduled_works+0x1d8/0x3d0 worker_thread+0x1fc/0x2f0 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Modules linked in: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc uinput rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci(O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) snd_hda_codec_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da7219 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic cfg80211 ecc gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- Fixes: ed9a3c0d4dd9 ("wifi: rtw89: wow: construct EAPoL packet for GTK rekey offload") Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240620055825.17592-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 0767f5fe9f48eda7a1920a3c64fcc45fd1e59c36 Author: Karthikeyan Periyasamy Date: Mon Jun 24 20:24:18 2024 +0530 wifi: ath12k: fix peer metadata parsing [ Upstream commit 1eeafd64c7b455381b77c546e41bc267e13e2809 ] Currently, the Rx data path only supports parsing peer metadata of version zero. However, the QCN9274 platform configures the peer metadata version as V1B. When V1B peer metadata is parsed using the version zero logic, invalid data is populated, causing valid packets to be dropped. To address this issue, refactor the peer metadata version and add the version based parsing to populate the data from peer metadata correctly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: 287033810990 ("wifi: ath12k: add support for peer meta data version") Signed-off-by: Karthikeyan Periyasamy Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20240624145418.2043461-1-quic_periyasa@quicinc.com Signed-off-by: Sasha Levin commit 23a9aab65585c63e04643fa4b2822a77f1dd2528 Author: Aloka Dixit Date: Wed May 8 13:29:04 2024 -0700 wifi: ath12k: advertise driver capabilities for MBSSID and EMA [ Upstream commit 519a545cfee790024c623c7aacd165f7431773d5 ] Advertise the driver support for multiple BSSID (MBSSID) and enhanced multi-BSSID advertisements (EMA) by setting extended capabilities. Configure mbssid_max_interfaces and ema_max_profile_periodicity fields in structure wiphy which are used to advertise maximum number of interfaces and profile periodicity supported by the driver. Add new WMI fields to configure maximum vdev count supported for MBSSID and profile periodicity in case of EMA. Set WMI_RSRC_CFG_FLAGS2_CALC_NEXT_DTIM_COUNT_SET flag to allow firmware to track and update the DTIM counts for each nontransmitted profile. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aloka Dixit Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240508202912.11902-2-quic_alokad@quicinc.com Stable-dep-of: 1eeafd64c7b4 ("wifi: ath12k: fix peer metadata parsing") Signed-off-by: Sasha Levin commit b33855de5c62d484eaef95db25b1b30fee49f492 Author: Johannes Berg Date: Tue Jun 25 19:51:10 2024 +0300 wifi: iwlwifi: mvm: always unblock EMLSR on ROC end [ Upstream commit f9068fe4fd49f9e4409c30546d7e16238942ce62 ] Since we always block EMLSR for ROC, we also need to always unblock it, even if we don't have a P2P device interface. Fix this. Fixes: a1efeb823084 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240625194805.96bbf98b716d.Id5a36954f8ebaa95142fd3d3a7a52bab5363b0bd@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9d5593e6b1639aebb609badbef95ba42664d5714 Author: Daniel Gabay Date: Tue Jun 18 20:03:03 2024 +0300 wifi: iwlwifi: fix iwl_mvm_get_valid_rx_ant() [ Upstream commit 0091eda01412805e0d2c8025638ac0992102a7fc ] Fix incorrect use of _tx_ valid ant data in the function. Fixes: 4ea1ed1d14d8 ("wifi: iwlwifi: mvm: support set_antenna()") Signed-off-by: Daniel Gabay Reviewed-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20240618200104.b7c6a320c7dc.I3092eb5275056f2162b9694e583c310c38568b2a@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 2f4182ef6adefb74245b2db64846479fa44284a0 Author: Johannes Berg Date: Wed Jun 12 14:35:57 2024 +0200 wifi: mac80211: correcty limit wider BW TDLS STAs [ Upstream commit 0b2d9d9aec2be212a28b7d14b5462c56d9adc3a3 ] When updating a channel context, the code can apply wider bandwidth TDLS STA channel definitions to each and every channel context used by the device, an approach that will surely lead to problems if there is ever more than one. Restrict the wider BW TDLS STA consideration to only TDLS STAs that are actually related to links using the channel context being updated. Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible") Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20240612143707.1ad989acecde.I5c75c94d95c3f4ea84f8ff4253189f4b13bad5c3@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 306d783dd1cf1371db46f938f7c4463f16bf5909 Author: Johannes Berg Date: Wed Jun 12 14:35:56 2024 +0200 wifi: mac80211: add ieee80211_tdls_sta_link_id() [ Upstream commit d42fcaece03654a4b21d2da88d68ed913e0b6c46 ] We've open-coded this twice and will need it again, add ieee80211_tdls_sta_link_id() to get the one link ID for a TDLS STA. Reviewed-by: Miriam Rachel Korenblit Link: https://patch.msgid.link/20240612143707.9f8141ae1725.I343822bbba0ae08dedb2f54a0ce87f2ae5ebeb2b@changeid Signed-off-by: Johannes Berg Stable-dep-of: 0b2d9d9aec2b ("wifi: mac80211: correcty limit wider BW TDLS STAs") Signed-off-by: Sasha Levin commit 28353278ee8c4a9e152a936eec2b8d48eecf7220 Author: Pablo Neira Ayuso Date: Mon Jun 3 20:16:59 2024 +0200 netfilter: nf_tables: rise cap on SELinux secmark context [ Upstream commit e29630247be24c3987e2b048f8e152771b32d38b ] secmark context is artificially limited 256 bytes, rise it to 4Kbytes. Fixes: fb961945457f ("netfilter: nf_tables: add SECMARK support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bb65059d251a3702f17009cd3816da2fff958657 Author: Ismael Luceno Date: Thu May 23 18:54:44 2024 +0200 ipvs: Avoid unnecessary calls to skb_is_gso_sctp [ Upstream commit 53796b03295cf7ab1fc8600016fa6dfbf4a494a0 ] In the context of the SCTP SNAT/DNAT handler, these calls can only return true. Fixes: e10d3ba4d434 ("ipvs: Fix checksumming on GSO of SCTP packets") Signed-off-by: Ismael Luceno Acked-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 8ecee44464a4926c9bef989a1490b7394785f584 Author: Steffen Klassert Date: Thu Jun 20 08:47:24 2024 +0200 xfrm: Fix unregister netdevice hang on hardware offload. [ Upstream commit 07b87f9eea0c30675084d50c82532d20168da009 ] When offloading xfrm states to hardware, the offloading device is attached to the skbs secpath. If a skb is free is deferred, an unregister netdevice hangs because the netdevice is still refcounted. Fix this by removing the netdevice from the xfrm states when the netdevice is unregistered. To find all xfrm states that need to be cleared we add another list where skbs linked to that are unlinked from the lists (deleted) but not yet freed. Fixes: d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 2845db7bedd84c9902efcecc4dd2e592a96b0f71 Author: Antoine Tenart Date: Mon Jun 24 11:09:07 2024 +0200 libbpf: Skip base btf sanity checks [ Upstream commit c73a9683cb21012b6c0f14217974837151c527a8 ] When upgrading to libbpf 1.3 we noticed a big performance hit while loading programs using CORE on non base-BTF symbols. This was tracked down to the new BTF sanity check logic. The issue is the base BTF definitions are checked first for the base BTF and then again for every module BTF. Loading 5 dummy programs (using libbpf-rs) that are using CORE on a non-base BTF symbol on my system: - Before this fix: 3s. - With this fix: 0.1s. Fix this by only checking the types starting at the BTF start id. This should ensure the base BTF is still checked as expected but only once (btf->start_id == 1 when creating the base BTF), and then only additional types are checked for each module BTF. Fixes: 3903802bb99a ("libbpf: Add basic BTF sanity validation") Signed-off-by: Antoine Tenart Signed-off-by: Andrii Nakryiko Reviewed-by: Alan Maguire Link: https://lore.kernel.org/bpf/20240624090908.171231-1-atenart@kernel.org Signed-off-by: Sasha Levin commit aeb79296c65cb92032b1744ed79ccd49424ddae6 Author: Donglin Peng Date: Wed Jun 19 05:23:55 2024 -0700 libbpf: Checking the btf_type kind when fixing variable offsets [ Upstream commit cc5083d1f3881624ad2de1f3cbb3a07e152cb254 ] I encountered an issue when building the test_progs from the repository [1]: $ pwd /work/Qemu/x86_64/linux-6.10-rc2/tools/testing/selftests/bpf/ $ make test_progs V=1 [...] ./tools/sbin/bpftool gen object ./ip_check_defrag.bpf.linked2.o ./ip_check_defrag.bpf.linked1.o libbpf: failed to find symbol for variable 'bpf_dynptr_slice' in section '.ksyms' Error: failed to link './ip_check_defrag.bpf.linked1.o': No such file or directory (2) [...] Upon investigation, I discovered that the btf_types referenced in the '.ksyms' section had a kind of BTF_KIND_FUNC instead of BTF_KIND_VAR: $ bpftool btf dump file ./ip_check_defrag.bpf.linked1.o [...] [2] DATASEC '.ksyms' size=0 vlen=2 type_id=16 offset=0 size=0 (FUNC 'bpf_dynptr_from_skb') type_id=17 offset=0 size=0 (FUNC 'bpf_dynptr_slice') [...] [16] FUNC 'bpf_dynptr_from_skb' type_id=82 linkage=extern [17] FUNC 'bpf_dynptr_slice' type_id=85 linkage=extern [...] For a detailed analysis, please refer to [2]. We can add a kind checking to fix the issue. [1] https://github.com/eddyz87/bpf/tree/binsort-btf-dedup [2] https://lore.kernel.org/all/0c0ef20c-c05e-4db9-bad7-2cbc0d6dfae7@oracle.com/ Fixes: 8fd27bf69b86 ("libbpf: Add BPF static linker BTF and BTF.ext support") Signed-off-by: Donglin Peng Signed-off-by: Daniel Borkmann Reviewed-by: Alan Maguire Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20240619122355.426405-1-dolinux.peng@gmail.com Signed-off-by: Sasha Levin commit fe60c691835edd35acb9821c3fafad51463df159 Author: Jiri Olsa Date: Wed Jun 19 10:16:24 2024 +0200 bpf: Change bpf_session_cookie return value to __u64 * [ Upstream commit 717d6313bba1b3179f0bf1026aaec6b7e26f484e ] This reverts [1] and changes return value for bpf_session_cookie in bpf selftests. Having long * might lead to problems on 32-bit architectures. Fixes: 2b8dd87332cd ("bpf: Make bpf_session_cookie() kfunc return long *") Suggested-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240619081624.1620152-1-jolsa@kernel.org Signed-off-by: Sasha Levin commit 00e09f86c6fa522c4c55b7305c1df4fa396930bf Author: Lukasz Majewski Date: Wed Jun 19 16:58:09 2024 +0200 net: dsa: ksz_common: Allow only up to two HSR HW offloaded ports for KSZ9477 [ Upstream commit dcec8d291da8813b5e1c7c0967ae63463a8521f6 ] The KSZ9477 allows HSR in-HW offloading for any of two selected ports. This patch adds check if one tries to use more than two ports with HSR offloading enabled. The problem is with RedBox configuration (HSR-SAN) - when configuring: ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 interlink lan3 \ supervision 45 version 1 The lan1 (port0) and lan2 (port1) are correctly configured as ports, which can use HSR offloading on ksz9477. However, when we do already have two bits set in hsr_ports, we need to return (-ENOTSUPP), so the interlink port (lan3) would be used with SW based HSR RedBox support. Otherwise, I do see some strange network behavior, as some HSR frames are visible on non-HSR network and vice versa. This causes the switch connected to interlink port (lan3) to drop frames and no communication is possible. Moreover, conceptually - the interlink (i.e. HSR-SAN port - lan3/port2) shall be only supported in software as it is also possible to use ksz9477 with only SW based HSR (i.e. port0/1 -> hsr0 with offloading, port2 -> HSR-SAN/interlink, port4/5 -> hsr1 with SW based HSR). Fixes: 5055cccfc2d1 ("net: hsr: Provide RedBox support (HSR-SAN)") Signed-off-by: Lukasz Majewski Reviewed-by: Andrew Lunn Reviewed-by: Dan Carpenter Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3bde02b27aacd58c0dd7fd76edcc929856c9c47b Author: Csókás, Bence Date: Wed Jun 19 14:31:11 2024 +0200 net: fec: Fix FEC_ECR_EN1588 being cleared on link-down [ Upstream commit c32fe1986f27cac329767d3497986e306cad1d5e ] FEC_ECR_EN1588 bit gets cleared after MAC reset in `fec_stop()`, which makes all 1588 functionality shut down, and all the extended registers disappear, on link-down, making the adapter fall back to compatibility "dumb mode". However, some functionality needs to be retained (e.g. PPS) even without link. Fixes: 6605b730c061 ("FEC: Add time stamping code and a PTP hardware clock") Cc: Richard Cochran Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/netdev/5fa9fadc-a89d-467a-aae9-c65469ff5fe1@lunn.ch/ Signed-off-by: Csókás, Bence Reviewed-by: Wei Fang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 40d7b3ed52449d36143bab8d3e70926aa61a60f4 Author: Jan Kara Date: Mon Jun 17 17:41:51 2024 +0200 udf: Fix bogus checksum computation in udf_rename() [ Upstream commit 27ab33854873e6fb958cb074681a0107cc2ecc4c ] Syzbot reports uninitialized memory access in udf_rename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udf_update_tag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udf_fiiter_write_fi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation. Fixes: e9109a92d2a9 ("udf: Convert udf_rename() to new directory iteration code") Link: https://lore.kernel.org/all/000000000000cf405f060d8f75a9@google.com/T/ Link: https://patch.msgid.link/20240617154201.29512-1-jack@suse.cz Reported-by: syzbot+d31185aa54170f7fc1f5@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 73c19830cd7234ee2aa0ff7f99becc6b99813e13 Author: Antony Antony Date: Tue Jun 11 08:32:15 2024 +0200 xfrm: Log input direction mismatch error in one place [ Upstream commit 15f5fe9e84839dcc9eaa69b08ced9d24cb464369 ] Previously, the offload data path decrypted the packet before checking the direction, leading to error logging and packet dropping. However, dropped packets wouldn't be visible in tcpdump or audit log. With this fix, the offload path, upon noticing SA direction mismatch, will pass the packet to the stack without decrypting it. The L3 layer will then log the error, audit, and drop ESP without decrypting or decapsulating it. This also ensures that the slow path records the error and audit log, making dropped packets visible in tcpdump. Fixes: 304b44f0d5a4 ("xfrm: Add dir validation to "in" data path lookup") Signed-off-by: Antony Antony Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit a4c10813bc394ff2b5c61f913971be216f8f8834 Author: Antony Antony Date: Tue Jun 11 08:31:29 2024 +0200 xfrm: Fix input error path memory access [ Upstream commit 54fcc6189dfb822eea984fa2b3e477a02447279d ] When there is a misconfiguration of input state slow path KASAN report error. Fix this error. west login: [ 52.987278] eth1: renamed from veth11 [ 53.078814] eth1: renamed from veth21 [ 53.181355] eth1: renamed from veth31 [ 54.921702] ================================================================== [ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295 [ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512 [ 54.924169] [ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25 [ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 54.926401] Call Trace: [ 54.926731] [ 54.927009] dump_stack_lvl+0x2a/0x3b [ 54.927478] kasan_report+0x84/0xa6 [ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295 [ 54.928410] xfrmi_rcv_cb+0x2d/0x295 [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e [ 54.929354] xfrm4_rcv_cb+0x46/0x5e [ 54.929804] xfrm_rcv_cb+0x7e/0xa1 [ 54.930240] xfrm_input+0x1b3a/0x1b96 [ 54.930715] ? xfrm_offload+0x41/0x41 [ 54.931182] ? raw_rcv+0x292/0x292 [ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2 [ 54.932158] ? skb_sec_path+0xd/0x3f [ 54.932610] ? xfrmi_input+0x90/0xce [ 54.933066] xfrm4_esp_rcv+0x33/0x54 [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2 [ 54.934089] ip_local_deliver_finish+0x110/0x120 [ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138 [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68 [ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168 [ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138 [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68 [ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 54.939904] ? ip_local_deliver_finish+0x120/0x120 [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107 [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2 [ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9 [ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38 [ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b [ 54.943618] process_backlog+0xb3/0x187 [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7 [ 54.944669] net_rx_action+0x1cb/0x380 [ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7 [ 54.945744] ? vring_new_virtqueue+0x17a/0x17a [ 54.946300] ? note_interrupt+0x2cd/0x367 [ 54.946805] handle_softirqs+0x13c/0x2c9 [ 54.947300] do_softirq+0x5f/0x7d [ 54.947727] [ 54.948014] [ 54.948300] __local_bh_enable_ip+0x48/0x62 [ 54.948832] __neigh_event_send+0x3fd/0x4ca [ 54.949361] neigh_resolve_output+0x1e/0x210 [ 54.949896] ip_finish_output2+0x4bf/0x4f0 [ 54.950410] ? __ip_finish_output+0x171/0x1b8 [ 54.950956] ip_send_skb+0x25/0x57 [ 54.951390] raw_sendmsg+0xf95/0x10c0 [ 54.951850] ? check_new_pages+0x45/0x71 [ 54.952343] ? raw_hash_sk+0x21b/0x21b [ 54.952815] ? kernel_init_pages+0x42/0x51 [ 54.953337] ? prep_new_page+0x44/0x51 [ 54.953811] ? get_page_from_freelist+0x72b/0x915 [ 54.954390] ? signal_pending_state+0x77/0x77 [ 54.954936] ? preempt_count_sub+0x14/0xb3 [ 54.955450] ? __might_resched+0x8a/0x240 [ 54.955951] ? __might_sleep+0x25/0xa0 [ 54.956424] ? first_zones_zonelist+0x2c/0x43 [ 54.956977] ? __rcu_read_lock+0x2d/0x3a [ 54.957476] ? __pte_offset_map+0x32/0xa4 [ 54.957980] ? __might_resched+0x8a/0x240 [ 54.958483] ? __might_sleep+0x25/0xa0 [ 54.958963] ? inet_send_prepare+0x54/0x54 [ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c [ 54.960000] sock_sendmsg_nosec+0x42/0x6c [ 54.960502] __sys_sendto+0x15d/0x1cc [ 54.960966] ? __x64_sys_getpeername+0x44/0x44 [ 54.961522] ? __handle_mm_fault+0x679/0xae4 [ 54.962068] ? find_vma+0x6b/0x8b [ 54.962497] ? find_vma_intersection+0x8a/0x8a [ 54.963052] ? handle_mm_fault+0x38/0x154 [ 54.963556] ? handle_mm_fault+0xeb/0x154 [ 54.964059] ? preempt_latency_start+0x29/0x34 [ 54.964613] ? preempt_count_sub+0x14/0xb3 [ 54.965141] ? up_read+0x4b/0x5c [ 54.965557] __x64_sys_sendto+0x76/0x82 [ 54.966041] do_syscall_64+0x69/0xd5 [ 54.966497] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 54.967119] RIP: 0033:0x7f2d2fec9a73 [ 54.967572] Code: 8b 15 a9 83 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 80 3d 71 0b 0d 00 00 41 89 ca 74 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 55 48 83 ec 30 44 89 4c 24 [ 54.969747] RSP: 002b:00007ffe85756418 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 54.970655] RAX: ffffffffffffffda RBX: 0000558bebad1340 RCX: 00007f2d2fec9a73 [ 54.971511] RDX: 0000000000000040 RSI: 0000558bebad73c0 RDI: 0000000000000003 [ 54.972366] RBP: 0000558bebad73c0 R08: 0000558bebad35c0 R09: 0000000000000010 [ 54.973234] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000040 [ 54.974091] R13: 00007ffe85757b00 R14: 0000001d00000001 R15: 0000558bebad4680 [ 54.974951] [ 54.975244] ================================================================== [ 54.976133] Disabling lock debugging due to kernel taint [ 54.976784] Oops: stack segment: 0000 [#1] PREEMPT DEBUG_PAGEALLOC KASAN [ 54.977603] CPU: 0 PID: 512 Comm: ping Tainted: G B 6.9.0-08574-gcd29a4313a1b #25 [ 54.978654] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 54.979750] RIP: 0010:xfrmi_rcv_cb+0x2d/0x295 [ 54.980293] Code: 00 00 41 57 41 56 41 89 f6 41 55 41 54 55 53 48 89 fb 51 85 f6 75 31 48 89 df e8 d7 e8 ff ff 48 89 c5 48 89 c7 e8 8b a4 4f ff <48> 8b 7d 00 48 89 ee e8 eb f3 ff ff 49 89 c5 b8 01 00 00 00 4d 85 [ 54.982462] RSP: 0018:ffffc90000007990 EFLAGS: 00010282 [ 54.983099] RAX: 0000000000000001 RBX: ffff8881126e9900 RCX: fffffbfff07b77cd [ 54.983948] RDX: fffffbfff07b77cd RSI: fffffbfff07b77cd RDI: ffffffff83dbbe60 [ 54.984794] RBP: 6b6b6b6b00000000 R08: 0000000000000008 R09: 0000000000000001 [ 54.985647] R10: ffffffff83dbbe67 R11: fffffbfff07b77cc R12: 00000000ffffffff [ 54.986512] R13: 00000000ffffffff R14: 00000000ffffffff R15: 0000000000000002 [ 54.987365] FS: 00007f2d2fc0dc40(0000) GS:ffffffff82eb2000(0000) knlGS:0000000000000000 [ 54.988329] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 54.989026] CR2: 00007ffe85755ff8 CR3: 0000000109941000 CR4: 0000000000350ef0 [ 54.989897] Call Trace: [ 54.990223] [ 54.990500] ? __die_body+0x1a/0x56 [ 54.990950] ? die+0x30/0x49 [ 54.991326] ? do_trap+0x9b/0x132 [ 54.991751] ? do_error_trap+0x7d/0xaf [ 54.992223] ? exc_stack_segment+0x35/0x45 [ 54.992734] ? asm_exc_stack_segment+0x22/0x30 [ 54.993294] ? xfrmi_rcv_cb+0x2d/0x295 [ 54.993764] ? xfrm4_rcv_cb+0x3d/0x5e [ 54.994228] xfrm4_rcv_cb+0x46/0x5e [ 54.994670] xfrm_rcv_cb+0x7e/0xa1 [ 54.995106] xfrm_input+0x1b3a/0x1b96 [ 54.995572] ? xfrm_offload+0x41/0x41 [ 54.996038] ? raw_rcv+0x292/0x292 [ 54.996472] ? nf_conntrack_confirm+0xa2/0xa2 [ 54.997011] ? skb_sec_path+0xd/0x3f [ 54.997466] ? xfrmi_input+0x90/0xce [ 54.997925] xfrm4_esp_rcv+0x33/0x54 [ 54.998378] ip_protocol_deliver_rcu+0xd7/0x1b2 [ 54.998944] ip_local_deliver_finish+0x110/0x120 [ 54.999520] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 55.000111] NF_HOOK.constprop.0+0xf8/0x138 [ 55.000630] ? ip_sublist_rcv_finish+0x68/0x68 [ 55.001195] ? secure_tcpv6_ts_off+0x23/0x168 [ 55.001743] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 55.002331] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 55.003008] NF_HOOK.constprop.0+0xf8/0x138 [ 55.003527] ? ip_sublist_rcv_finish+0x68/0x68 [ 55.004078] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 55.004755] ? ip_local_deliver_finish+0x120/0x120 [ 55.005351] __netif_receive_skb_one_core+0xc9/0x107 [ 55.005972] ? __netif_receive_skb_list_core+0x1c2/0x1c2 [ 55.006626] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9 [ 55.007266] ? blk_mq_start_stopped_hw_queue+0x38/0x38 [ 55.007899] ? virtqueue_get_buf_ctx+0x295/0x46b [ 55.008476] process_backlog+0xb3/0x187 [ 55.008961] __napi_poll.constprop.0+0x57/0x1a7 [ 55.009540] net_rx_action+0x1cb/0x380 [ 55.010020] ? __napi_poll.constprop.0+0x1a7/0x1a7 [ 55.010610] ? vring_new_virtqueue+0x17a/0x17a [ 55.011173] ? note_interrupt+0x2cd/0x367 [ 55.011675] handle_softirqs+0x13c/0x2c9 [ 55.012169] do_softirq+0x5f/0x7d [ 55.012597] [ 55.012882] [ 55.013179] __local_bh_enable_ip+0x48/0x62 [ 55.013704] __neigh_event_send+0x3fd/0x4ca [ 55.014227] neigh_resolve_output+0x1e/0x210 [ 55.014761] ip_finish_output2+0x4bf/0x4f0 [ 55.015278] ? __ip_finish_output+0x171/0x1b8 [ 55.015823] ip_send_skb+0x25/0x57 [ 55.016261] raw_sendmsg+0xf95/0x10c0 [ 55.016729] ? check_new_pages+0x45/0x71 [ 55.017229] ? raw_hash_sk+0x21b/0x21b [ 55.017708] ? kernel_init_pages+0x42/0x51 [ 55.018225] ? prep_new_page+0x44/0x51 [ 55.018704] ? get_page_from_freelist+0x72b/0x915 [ 55.019292] ? signal_pending_state+0x77/0x77 [ 55.019840] ? preempt_count_sub+0x14/0xb3 [ 55.020357] ? __might_resched+0x8a/0x240 [ 55.020860] ? __might_sleep+0x25/0xa0 [ 55.021345] ? first_zones_zonelist+0x2c/0x43 [ 55.021896] ? __rcu_read_lock+0x2d/0x3a [ 55.022396] ? __pte_offset_map+0x32/0xa4 [ 55.022901] ? __might_resched+0x8a/0x240 [ 55.023404] ? __might_sleep+0x25/0xa0 [ 55.023879] ? inet_send_prepare+0x54/0x54 [ 55.024391] ? sock_sendmsg_nosec+0x42/0x6c [ 55.024918] sock_sendmsg_nosec+0x42/0x6c [ 55.025428] __sys_sendto+0x15d/0x1cc [ 55.025892] ? __x64_sys_getpeername+0x44/0x44 [ 55.026441] ? __handle_mm_fault+0x679/0xae4 [ 55.026988] ? find_vma+0x6b/0x8b [ 55.027414] ? find_vma_intersection+0x8a/0x8a [ 55.027966] ? handle_mm_fault+0x38/0x154 [ 55.028470] ? handle_mm_fault+0xeb/0x154 [ 55.028972] ? preempt_latency_start+0x29/0x34 [ 55.029532] ? preempt_count_sub+0x14/0xb3 [ 55.030047] ? up_read+0x4b/0x5c [ 55.030463] __x64_sys_sendto+0x76/0x82 [ 55.030949] do_syscall_64+0x69/0xd5 [ 55.031406] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 55.032028] RIP: 0033:0x7f2d2fec9a73 [ 55.032481] Code: 8b 15 a9 83 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 80 3d 71 0b 0d 00 00 41 89 ca 74 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 55 48 83 ec 30 44 89 4c 24 [ 55.034660] RSP: 002b:00007ffe85756418 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 55.035567] RAX: ffffffffffffffda RBX: 0000558bebad1340 RCX: 00007f2d2fec9a73 [ 55.036424] RDX: 0000000000000040 RSI: 0000558bebad73c0 RDI: 0000000000000003 [ 55.037293] RBP: 0000558bebad73c0 R08: 0000558bebad35c0 R09: 0000000000000010 [ 55.038153] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000040 [ 55.039012] R13: 00007ffe85757b00 R14: 0000001d00000001 R15: 0000558bebad4680 [ 55.039871] [ 55.040167] Modules linked in: [ 55.040585] ---[ end trace 0000000000000000 ]--- [ 55.041164] RIP: 0010:xfrmi_rcv_cb+0x2d/0x295 [ 55.041714] Code: 00 00 41 57 41 56 41 89 f6 41 55 41 54 55 53 48 89 fb 51 85 f6 75 31 48 89 df e8 d7 e8 ff ff 48 89 c5 48 89 c7 e8 8b a4 4f ff <48> 8b 7d 00 48 89 ee e8 eb f3 ff ff 49 89 c5 b8 01 00 00 00 4d 85 [ 55.043889] RSP: 0018:ffffc90000007990 EFLAGS: 00010282 [ 55.044528] RAX: 0000000000000001 RBX: ffff8881126e9900 RCX: fffffbfff07b77cd [ 55.045386] RDX: fffffbfff07b77cd RSI: fffffbfff07b77cd RDI: ffffffff83dbbe60 [ 55.046250] RBP: 6b6b6b6b00000000 R08: 0000000000000008 R09: 0000000000000001 [ 55.047104] R10: ffffffff83dbbe67 R11: fffffbfff07b77cc R12: 00000000ffffffff [ 55.047960] R13: 00000000ffffffff R14: 00000000ffffffff R15: 0000000000000002 [ 55.048820] FS: 00007f2d2fc0dc40(0000) GS:ffffffff82eb2000(0000) knlGS:0000000000000000 [ 55.049805] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 55.050507] CR2: 00007ffe85755ff8 CR3: 0000000109941000 CR4: 0000000000350ef0 [ 55.051366] Kernel panic - not syncing: Fatal exception in interrupt [ 55.052136] Kernel Offset: disabled [ 55.052577] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Fixes: 304b44f0d5a4 ("xfrm: Add dir validation to "in" data path lookup") Signed-off-by: Antony Antony Reviewed-by: Simon Horman Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8ca4ec5a59d344c88232785d7be326a4a80388da Author: Daniel Xu Date: Wed Jun 12 09:58:30 2024 -0600 bpf: Make bpf_session_cookie() kfunc return long * [ Upstream commit 2b8dd87332cd2782b5b3f0c423bd6693e487ed30 ] We will soon be generating kfunc prototypes from BTF. As part of that, we need to align the manual signatures in bpf_kfuncs.h with the actual kfunc definitions. There is currently a conflicting signature for bpf_session_cookie() w.r.t. return type. The original intent was to return long * and not __u64 *. You can see evidence of that intent in a3a5113393cc ("selftests/bpf: Add kprobe session cookie test"). Fix conflict by changing kfunc definition. Fixes: 5c919acef851 ("bpf: Add support for kprobe session cookie") Signed-off-by: Daniel Xu Link: https://lore.kernel.org/r/7043e1c251ab33151d6e3830f8ea1902ed2604ac.1718207789.git.dxu@dxuuu.xyz Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ddbd23de1d2dd221dabc375515846c48b6d96b0d Author: Johannes Berg Date: Wed Jun 5 14:07:36 2024 +0300 wifi: iwlwifi: mvm: separate non-BSS/ROC EMLSR blocking [ Upstream commit 5f1fee9644759d07f3d3a468389c7c18027083d7 ] If non-BSS and remain-on-channel (ROC) blocking were to occur simultaneously, they'd step on each other's toes, unblocking when not yet supported. Disentangle these bits, and ROC doesn't need to use the non_bss_link() function then. Fixes: a1efeb823084 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240605140556.461fcf7b95bb.Id0d21dcb739d426ff15ec068b5df8abaab58884d@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 94d2e5b7866da242ede7ea855b4b529fcedddc22 Author: Miri Korenblit Date: Wed Jun 5 14:05:06 2024 +0300 wifi: iwlwifi: mvm: fix re-enabling EMLSR [ Upstream commit bd40215b19d255b433a91a8bb8088937e5db4284 ] When EMLSR gets unblocked, the current code checks if the last exit was due to an EXIT reason (as opposed to a BLOCKING one), and if so, it does nothing, as in this case a MLO scan was scheduled to run in 30 seconds. But the code doesn't consider the time that passed from the last exit, so if immediately after the exit a blocker occurred (e.g. non-BSS interface), and lasts for more than 30 seconds, then the MLO scan and the following link selection will decide not to enter EMLSR, and when the unblocking event finally happens, the reason is still set to the EXIT one, so it will do nothing, and we will not have the chance to re-enable EMLSR. Fix this by checking also the time that has passed since the last exit, only if it is less than 30 seconds, we can count on the scheduled MLO scan. Note that clearing the reason itself can't be done since it is needed for the EMLSR prevention mechanism. Fixes: 2f33561ea8f9 ("wifi: iwlwifi: mvm: trigger link selection after exiting EMLSR") Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://msgid.link/20240605140327.58556fc4cfa9.I4c55b3cd9f20b21b37f28258d0fb6842ba413966@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 07117ccf537315cc55944b1a9b19c668dae2b010 Author: Johannes Berg Date: Thu May 23 12:09:42 2024 +0200 wifi: nl80211: expose can-monitor channel property [ Upstream commit f3269b7912f75b6e34926334377ede45656a8950 ] It may be possible to monitor on disabled channels per the can-monitor flag, but evidently I forgot to expose that out to userspace. Fix that. Fixes: a110a3b79177 ("wifi: cfg80211: optionally support monitor on disabled channels") Reviewed-by: Miriam Rachel Korenblit Reviewed-by: Ilan Peer Signed-off-by: Johannes Berg Link: https://msgid.link/20240523120945.9a2c19a51e53.I50fa1b1a18b70f63a5095131ac23dc2e71f3d426@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 19eaf4f2f5a981f55a265242ada2bf92b0c742dd Author: Baochen Qiang Date: Thu Jun 6 10:06:53 2024 +0800 wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() [ Upstream commit bcbd771cd5d68c0c52567556097d75f9fc4e7cd6 ] Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c70efd8546e653fd927602085c4129674f42828f Author: Baochen Qiang Date: Thu Jun 6 10:06:52 2024 +0800 wifi: cfg80211: fix typo in cfg80211_calculate_bitrate_he() [ Upstream commit 9ee0d44f055276fe2802b2f65058e920853f4f99 ] rates_996 is mistakenly written as rates_969, fix it. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang Link: https://msgid.link/20240606020653.33205-2-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 7a00a36b656de02d9e5512d8b009ab15d20b67ea Author: Aditya Kumar Singh Date: Tue Jun 11 09:42:32 2024 +0300 wifi: ath12k: fix per pdev debugfs registration [ Upstream commit 8dd65ccbdf91e2fe3ab6e4da158b38f81746c3b4 ] Function ath12k_debugfs_register() is called once inside the function ath12k_mac_hw_register(). However, with single wiphy model, there could be multiple pdevs registered under single hardware. Hence, need to register debugfs for each one of them. Move the caller inside the loop which iterates over all underlying pdevs. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: f8bde02a26b9 ("wifi: ath12k: initial debugfs support") Signed-off-by: Aditya Kumar Singh Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240529043043.2488031-2-quic_adisi@quicinc.com Signed-off-by: Sasha Levin commit 1d291225c40b88e3334b7b51c34fccf9baad823a Author: Baochen Qiang Date: Tue Jun 11 09:42:34 2024 +0300 wifi: ath11k: fix wrong handling of CCMP256 and GCMP ciphers [ Upstream commit d2b0ca38d362ebf16ca79cd7f309d5bb8b581deb ] Currently for CCMP256, GCMP128 and GCMP256 ciphers, in ath11k_install_key() IEEE80211_KEY_FLAG_GENERATE_IV_MGMT is not set. And in ath11k_mac_mgmt_tx_wmi() a length of IEEE80211_CCMP_MIC_LEN is reserved for all ciphers. This results in unexpected management frame drop in case either of above 3 ciphers is used. The reason is, without IEEE80211_KEY_FLAG_GENERATE_IV_MGMT set, mac80211 will not generate CCMP/GCMP headers in frame for ath11k. Also MIC length reserved is wrong. Such frame is dropped later by hardware: ath11k_pci 0000:5a:00.0: mac tx mgmt frame, buf id 0 ath11k_pci 0000:5a:00.0: mgmt tx compl ev pdev_id 1, desc_id 0, status 1 From user point of view, we have observed very low throughput due to this issue: action frames are all dropped so ADDBA response from DUT never reaches AP. AP can not use aggregation thus throughput is low. Fix this by setting IEEE80211_KEY_FLAG_GENERATE_IV_MGMT flag and by reserving proper MIC length for those ciphers. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Reported-by: Yaroslav Isakov Tested-by: Yaroslav Isakov Closes: https://lore.kernel.org/all/CADS+iDX5=JtJr0apAtAQ02WWBxgOFEv8G063vuGYwDTC8AVZaw@mail.gmail.com Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240605014826.22498-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 630c62b46835714704c4c4320f95833f77516aa6 Author: Baochen Qiang Date: Tue Jun 11 09:42:33 2024 +0300 wifi: ath12k: fix ACPI warning when resume [ Upstream commit 8b2a12749b08726f006303814ecc1c37024d3617 ] Currently ACPI notification handler is installed when driver loads and only gets removed when driver unloads. During resume after firmware is reloaded, ath12k tries to install it by default. Since it is installed already, ACPI subsystem rejects it and returns an error: [ 83.094206] ath12k_pci 0000:03:00.0: failed to install DSM notify callback: 7 Fix it by removing that handler when going to suspend. This also avoid any possible ACPI call to firmware before firmware is reloaded/reinitialized. Note ab->acpi also needs to be cleared in ath12k_acpi_stop() such that we are in a clean state when ACPI structures are reinitialized in ath12k_acpi_start(). Tested-on: WCN7850 HW2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 576771c9fa21 ("wifi: ath12k: ACPI TAS support") Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240531024000.9291-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 53c7c8ed563da7fe98f68afc8b4710412c764d4a Author: Thomas Gleixner Date: Mon Jun 10 14:46:36 2024 +0200 jump_label: Fix concurrency issues in static_key_slow_dec() [ Upstream commit 83ab38ef0a0b2407d43af9575bb32333fdd74fb2 ] The commit which tried to fix the concurrency issues of concurrent static_key_slow_inc() failed to fix the equivalent issues vs. static_key_slow_dec(): CPU0 CPU1 static_key_slow_dec() static_key_slow_try_dec() key->enabled == 1 val = atomic_fetch_add_unless(&key->enabled, -1, 1); if (val == 1) return false; jump_label_lock(); if (atomic_dec_and_test(&key->enabled)) { --> key->enabled == 0 __jump_label_update() static_key_slow_dec() static_key_slow_try_dec() key->enabled == 0 val = atomic_fetch_add_unless(&key->enabled, -1, 1); --> key->enabled == -1 <- FAIL There is another bug in that code, when there is a concurrent static_key_slow_inc() which enables the key as that sets key->enabled to -1 so on the other CPU val = atomic_fetch_add_unless(&key->enabled, -1, 1); will succeed and decrement to -2, which is invalid. Cure all of this by replacing the atomic_fetch_add_unless() with a atomic_try_cmpxchg() loop similar to static_key_fast_inc_not_disabled(). [peterz: add WARN_ON_ONCE for the -1 race] Fixes: 4c5ea0a9cd02 ("locking/static_key: Fix concurrent static_key_slow_inc()") Reported-by: Yue Sun Reported-by: Xingwei Lee Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20240610124406.422897838@linutronix.de Signed-off-by: Sasha Levin commit 7e4a0c17a81d373bbeccfcc41face27ff13713b0 Author: Thomas Gleixner Date: Mon Jun 10 14:46:35 2024 +0200 perf/x86: Serialize set_attr_rdpmc() [ Upstream commit bb9bb45f746b0f9457de9c3fc4da143a6351bdc9 ] Yue and Xingwei reported a jump label failure. It's caused by the lack of serialization in set_attr_rdpmc(): CPU0 CPU1 Assume: x86_pmu.attr_rdpmc == 0 if (val != x86_pmu.attr_rdpmc) { if (val == 0) ... else if (x86_pmu.attr_rdpmc == 0) static_branch_dec(&rdpmc_never_available_key); if (val != x86_pmu.attr_rdpmc) { if (val == 0) ... else if (x86_pmu.attr_rdpmc == 0) FAIL, due to imbalance ---> static_branch_dec(&rdpmc_never_available_key); The reported BUG() is a consequence of the above and of another bug in the jump label core code. The core code needs a separate fix, but that cannot prevent the imbalance problem caused by set_attr_rdpmc(). Prevent this by serializing set_attr_rdpmc() locally. Fixes: a66734297f78 ("perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks") Closes: https://lore.kernel.org/r/CAEkJfYNzfW1vG=ZTMdz_Weoo=RXY1NDunbxnDaLyj8R4kEoE_w@mail.gmail.com Reported-by: Yue Sun Reported-by: Xingwei Lee Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20240610124406.359476013@linutronix.de Signed-off-by: Sasha Levin commit 431342f4ba521131fd4c05e15d3ea03948b110e8 Author: Ido Schimmel Date: Thu Jun 6 16:49:43 2024 +0200 mlxsw: spectrum_acl: Fix ACL scale regression and firmware errors [ Upstream commit 75d8d7a63065b18df9555dbaab0b42d4c6f20943 ] ACLs that reside in the algorithmic TCAM (A-TCAM) in Spectrum-2 and newer ASICs can share the same mask if their masks only differ in up to 8 consecutive bits. For example, consider the following filters: # tc filter add dev swp1 ingress pref 1 proto ip flower dst_ip 192.0.2.0/24 action drop # tc filter add dev swp1 ingress pref 1 proto ip flower dst_ip 198.51.100.128/25 action drop The second filter can use the same mask as the first (dst_ip/24) with a delta of 1 bit. However, the above only works because the two filters have different values in the common unmasked part (dst_ip/24). When entries have the same value in the common unmasked part they create undesired collisions in the device since many entries now have the same key. This leads to firmware errors such as [1] and to a reduced scale. Fix by adjusting the hash table key to only include the value in the common unmasked part. That is, without including the delta bits. That way the driver will detect the collision during filter insertion and spill the filter into the circuit TCAM (C-TCAM). Add a test case that fails without the fix and adjust existing cases that check C-TCAM spillage according to the above limitation. [1] mlxsw_spectrum2 0000:06:00.0: EMAD reg access failed (tid=3379b18a00003394,reg_id=3027(ptce3),type=write,status=8(resource not available)) Fixes: c22291f7cf45 ("mlxsw: spectrum: acl: Implement delta for ERP") Reported-by: Alexander Zubkov Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Tested-by: Alexander Zubkov Signed-off-by: Petr Machata Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb5d4fc578e655d113f09565f6f047e15f7ab578 Author: Ido Schimmel Date: Thu Jun 6 16:49:42 2024 +0200 mlxsw: spectrum_acl_erp: Fix object nesting warning [ Upstream commit 97d833ceb27dc19f8777d63f90be4a27b5daeedf ] ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM. The above can result in the following set of hints: H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition. Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication. This can eventually lead to nested objects which are not supported by the library [1]. Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches. I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour. Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next. [1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Call Trace: __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 Fixes: 9069a3817d82 ("lib: objagg: implement optimization hints assembly and use hints for object creation") Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Tested-by: Alexander Zubkov Signed-off-by: Petr Machata Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 499f742fed42e74f1321f4b12ca196a66a2b49fc Author: Ido Schimmel Date: Thu Jun 6 16:49:41 2024 +0200 lib: objagg: Fix general protection fault [ Upstream commit b4a3a89fffcdf09702b1f161b914e52abca1894d ] The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported. Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects. Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1]. Before fixing the root cause, error out when nesting happens and warn. [1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 Fixes: 9069a3817d82 ("lib: objagg: implement optimization hints assembly and use hints for object creation") Reported-by: Alexander Zubkov Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Tested-by: Alexander Zubkov Signed-off-by: Petr Machata Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a1cf0f193db577a8d682ec54ff9e3cf1e134b96d Author: Sean Christopherson Date: Mon May 27 17:34:48 2024 -0700 sched/core: Drop spinlocks on contention iff kernel is preemptible [ Upstream commit c793a62823d1ce8f70d9cfc7803e3ea436277cda ] Use preempt_model_preemptible() to detect a preemptible kernel when deciding whether or not to reschedule in order to drop a contended spinlock or rwlock. Because PREEMPT_DYNAMIC selects PREEMPTION, kernels built with PREEMPT_DYNAMIC=y will yield contended locks even if the live preemption model is "none" or "voluntary". In short, make kernels with dynamically selected models behave the same as kernels with statically selected models. Somewhat counter-intuitively, NOT yielding a lock can provide better latency for the relevant tasks/processes. E.g. KVM x86's mmu_lock, a rwlock, is often contended between an invalidation event (takes mmu_lock for write) and a vCPU servicing a guest page fault (takes mmu_lock for read). For _some_ setups, letting the invalidation task complete even if there is mmu_lock contention provides lower latency for *all* tasks, i.e. the invalidation completes sooner *and* the vCPU services the guest page fault sooner. But even KVM's mmu_lock behavior isn't uniform, e.g. the "best" behavior can vary depending on the host VMM, the guest workload, the number of vCPUs, the number of pCPUs in the host, why there is lock contention, etc. In other words, simply deleting the CONFIG_PREEMPTION guard (or doing the opposite and removing contention yielding entirely) needs to come with a big pile of data proving that changing the status quo is a net positive. Opportunistically document this side effect of preempt=full, as yielding contended spinlocks can have significant, user-visible impact. Fixes: c597bfddc9e9 ("sched: Provide Kconfig support for default dynamic preempt mode") Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ankur Arora Reviewed-by: Chen Yu Link: https://lore.kernel.org/kvm/ef81ff36-64bb-4cfe-ae9b-e3acf47bff24@proxmox.com Signed-off-by: Sasha Levin commit b20578a3a2e67da384dc79b3d8117f36e372eea0 Author: Sean Christopherson Date: Mon May 27 17:34:47 2024 -0700 sched/core: Move preempt_model_*() helpers from sched.h to preempt.h [ Upstream commit f0dc887f21d18791037c0166f652c67da761f16f ] Move the declarations and inlined implementations of the preempt_model_*() helpers to preempt.h so that they can be referenced in spinlock.h without creating a potential circular dependency between spinlock.h and sched.h. No functional change intended. Signed-off-by: Sean Christopherson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Ankur Arora Link: https://lkml.kernel.org/r/20240528003521.979836-2-ankur.a.arora@oracle.com Stable-dep-of: c793a62823d1 ("sched/core: Drop spinlocks on contention iff kernel is preemptible") Signed-off-by: Sasha Levin commit 50b556a1ce2cbcb284ee611c9ee8af2d578f9d76 Author: Jan Kara Date: Mon May 20 15:23:37 2024 +0200 udf: Fix lock ordering in udf_evict_inode() [ Upstream commit 8832fc1e502687869606bb0a7b79848ed3bf036f ] udf_evict_inode() calls udf_setsize() to truncate deleted inode. However inode deletion through udf_evict_inode() can happen from inode reclaim context and udf_setsize() grabs mapping->invalidate_lock which isn't generally safe to acquire from fs reclaim context since we allocate pages under mapping->invalidate_lock for example in a page fault path. This is however not a real deadlock possibility as by the time udf_evict_inode() is called, nobody can be accessing the inode, even less work with its page cache. So this is just a lockdep triggering false positive. Fix the problem by moving mapping->invalidate_lock locking outsize of udf_setsize() into udf_setattr() as grabbing mapping->invalidate_lock from udf_evict_inode() is pointless. Reported-by: syzbot+0333a6f4b88bcd68a62f@syzkaller.appspotmail.com Fixes: b9a861fd527a ("udf: Protect truncate and file type conversion with invalidate_lock") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit bd334e2f45a813c270776583d3a97b31a2979191 Author: Geliang Tang Date: Thu May 23 14:50:03 2024 +0800 selftests/bpf: Check length of recv in test_sockmap [ Upstream commit de1b5ea789dc28066cc8dc634b6825bd6148f38b ] The value of recv in msg_loop may be negative, like EWOULDBLOCK, so it's necessary to check if it is positive before accumulating it to bytes_recvd. Fixes: 16962b2404ac ("bpf: sockmap, add selftests") Signed-off-by: Geliang Tang Signed-off-by: Daniel Borkmann Tested-by: Jakub Sitnicki Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/5172563f7c7b2a2e953cef02e89fc34664a7b190.1716446893.git.tanggeliang@kylinos.cn Signed-off-by: Sasha Levin commit befa4793310998125c34ecb3cdb81eef5c0a0fb6 Author: Guangguan Wang Date: Mon Jun 3 11:00:18 2024 +0800 net/smc: set rmb's SG_MAX_SINGLE_ALLOC limitation only when CONFIG_ARCH_NO_SG_CHAIN is defined [ Upstream commit 3ac14b9dfbd345e891d48d89f6c2fa519848f0f4 ] SG_MAX_SINGLE_ALLOC is used to limit maximum number of entries that will be allocated in one piece of scatterlist. When the entries of scatterlist exceeds SG_MAX_SINGLE_ALLOC, sg chain will be used. From commit 7c703e54cc71 ("arch: switch the default on ARCH_HAS_SG_CHAIN"), we can know that the macro CONFIG_ARCH_NO_SG_CHAIN is used to identify whether sg chain is supported. So, SMC-R's rmb buffer should be limited by SG_MAX_SINGLE_ALLOC only when the macro CONFIG_ARCH_NO_SG_CHAIN is defined. Fixes: a3fe3d01bd0d ("net/smc: introduce sg-logic for RMBs") Signed-off-by: Guangguan Wang Co-developed-by: Wen Gu Signed-off-by: Wen Gu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6f67fff74f1b28652a16a437351d8ac406a559f Author: Andrii Nakryiko Date: Wed May 29 15:32:39 2024 -0700 libbpf: keep FD_CLOEXEC flag when dup()'ing FD [ Upstream commit 531876c80004ecff7bfdbd8ba6c6b48835ef5e22 ] Make sure to preserve and/or enforce FD_CLOEXEC flag on duped FDs. Use dup3() with O_CLOEXEC flag for that. Without this fix libbpf effectively clears FD_CLOEXEC flag on each of BPF map/prog FD, which is definitely not the right or expected behavior. Reported-by: Lennart Poettering Fixes: bc308d011ab8 ("libbpf: call dup2() syscall directly") Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Link: https://lore.kernel.org/r/20240529223239.504241-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1a07de1959cae5d6db865456734a3e1dcb9e0295 Author: Arnd Bergmann Date: Tue May 28 18:15:25 2024 +0200 hns3: avoid linking objects into multiple modules [ Upstream commit e3bbb994a7e0ead1e028c5a8ec5f8526b4a9c5c9 ] Each object file contains information about which module it gets linked into, so linking the same file into multiple modules now causes a warning: scripts/Makefile.build:254: drivers/net/ethernet/hisilicon/hns3/Makefile: hns3_common/hclge_comm_cmd.o is added to multiple modules: hclge hclgevf scripts/Makefile.build:254: drivers/net/ethernet/hisilicon/hns3/Makefile: hns3_common/hclge_comm_rss.o is added to multiple modules: hclge hclgevf scripts/Makefile.build:254: drivers/net/ethernet/hisilicon/hns3/Makefile: hns3_common/hclge_comm_tqp_stats.o is added to multiple modules: hclge hclgevf Change the way that hns3 is built by moving the three common files into a separate module with exported symbols instead. Fixes: 5f20be4e90e6 ("net: hns3: refactor hns3 makefile to support hns3_common module") Signed-off-by: Arnd Bergmann Reviewed-by: Jacob Keller Link: https://lore.kernel.org/r/20240528161603.2443125-1-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5e8a0b94c58f9330ea6416014d17d49063fca2fc Author: Eric Dumazet Date: Tue May 28 12:52:53 2024 +0000 tcp: fix races in tcp_v[46]_err() [ Upstream commit fde6f897f2a184546bf5516ac736523ef24dc6a7 ] These functions have races when they: 1) Write sk->sk_err 2) call sk_error_report(sk) 3) call tcp_done(sk) As described in prior patches in this series: An smp_wmb() is missing. We should call tcp_done() before sk_error_report(sk) to have consistent tcp_poll() results on SMP hosts. Use tcp_done_with_error() where we centralized the correct sequence. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Link: https://lore.kernel.org/r/20240528125253.1966136-5-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c6034cae002ba9be7d13e96dbab871d6008974a Author: Eric Dumazet Date: Tue May 28 12:52:52 2024 +0000 tcp: fix races in tcp_abort() [ Upstream commit 5ce4645c23cf5f048eb8e9ce49e514bababdee85 ] tcp_abort() has the same issue than the one fixed in the prior patch in tcp_write_err(). In order to get consistent results from tcp_poll(), we must call sk_error_report() after tcp_done(). We can use tcp_done_with_error() to centralize this logic. Fixes: c1e64e298b8c ("net: diag: Support destroying TCP sockets.") Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Link: https://lore.kernel.org/r/20240528125253.1966136-4-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c366435a152b8e4f53f7fcf4752d81df877a39e0 Author: Eric Dumazet Date: Tue May 28 12:52:51 2024 +0000 tcp: fix race in tcp_write_err() [ Upstream commit 853c3bd7b7917670224c9fe5245bd045cac411dd ] I noticed flakes in a packetdrill test, expecting an epoll_wait() to return EPOLLERR | EPOLLHUP on a failed connect() attempt, after multiple SYN retransmits. It sometimes return EPOLLERR only. The issue is that tcp_write_err(): 1) writes an error in sk->sk_err, 2) calls sk_error_report(), 3) then calls tcp_done(). tcp_done() is writing SHUTDOWN_MASK into sk->sk_shutdown, among other things. Problem is that the awaken user thread (from 2) sk_error_report()) might call tcp_poll() before tcp_done() has written sk->sk_shutdown. tcp_poll() only sees a non zero sk->sk_err and returns EPOLLERR. This patch fixes the issue by making sure to call sk_error_report() after tcp_done(). tcp_write_err() also lacks an smp_wmb(). We can reuse tcp_done_with_error() to factor out the details, as Neal suggested. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Link: https://lore.kernel.org/r/20240528125253.1966136-3-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea734f7724ebbb7a020aa69f134dd4f6be606183 Author: Eric Dumazet Date: Tue May 28 12:52:50 2024 +0000 tcp: add tcp_done_with_error() helper [ Upstream commit 5e514f1cba090e1c8fff03e92a175eccfe46305f ] tcp_reset() ends with a sequence that is carefuly ordered. We need to fix [e]poll bugs in the following patches, it makes sense to use a common helper. Suggested-by: Neal Cardwell Signed-off-by: Eric Dumazet Acked-by: Neal Cardwell Link: https://lore.kernel.org/r/20240528125253.1966136-2-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 853c3bd7b791 ("tcp: fix race in tcp_write_err()") Signed-off-by: Sasha Levin commit 13829bfb38bcfc0d943b734313376b336d732c48 Author: Linus Walleij Date: Mon May 27 21:26:44 2024 +0200 net: ethernet: cortina: Restore TSO support [ Upstream commit 2942dfab630444d46aaa37fb7d629b620abbf6ba ] An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac631873c9e7 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 04d8b7a21c0062f9760f579cbcc12797f6fd43e6 Author: Baochen Qiang Date: Fri May 24 10:40:21 2024 +0800 wifi: ath12k: fix wrong definition of CE ring's base address [ Upstream commit 0ae570703754858a77cc42b3c9fff42e9f084608 ] Base address of CE ring is defined as u32, currently this works because DMA mask configured as 32 bit: #define ATH12K_PCI_DMA_MASK 32 However this mask could be changed once firmware bugs are fixed to fully support 36 bit DMA addressing. So to protect against any future changes to the DMA mask, change the type of the fields that are dependent upon it. This is found during code review. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240524024021.37711-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 5c7db8b09fbaad5141359a9da2a7b27f21059728 Author: Baochen Qiang Date: Fri May 24 10:15:58 2024 +0800 wifi: ath11k: fix wrong definition of CE ring's base address [ Upstream commit 5714e25f1d1875b300fb337dadfaa75324c1161a ] Base address of CE ring is defined as u32, currently this works because coherent DMA mask configured as 32 bit: #define ATH11K_PCI_COHERENT_DMA_MASK 32 However this mask could be changed once firmware bugs are fixed to fully support 36 bit DMA addressing. So to protect against any future changes to the DMA mask, change the type of the fields that are dependent upon it. This is found during code review. Compile tested only. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240524021558.34452-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit bdfbf56652d5c07cc14873b2ecacd6214f89cd79 Author: Ping-Ke Shih Date: Tue May 21 12:01:39 2024 +0800 wifi: rtw89: 8852c: correct logic and restore PCI PHY EQ after device resume [ Upstream commit 9e305a6f01ad539dc134b8017521495378d8e00e ] PCI PHY EQ value is missing after card off/on, so update the value after device resume. The original commit only updates once at probe stage, which could lead problem after suspend/resume. The logic should be read a value from one register and write to another register with a mask to avoid affecting unrelated bits. Fixes: a78d33a1286c ("wifi: rtw89: 8852c: disable PCI PHY EQ to improve compatibility") Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240521040139.20311-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 95d4e829e50e2d68154d6f30697012de8984ac1d Author: P Praneesh Date: Mon May 20 12:30:45 2024 +0530 wifi: ath12k: fix firmware crash during reo reinject [ Upstream commit a57ab7cced454f69b8ee8aa5f5019ea8de4674da ] When handling fragmented packets, the ath12k driver reassembles each fragment into a normal packet and then reinjects it into the HW ring. However, a firmware crash occurs during this reinjection process. The issue arises because the driver populates peer metadata in reo_ent_ring->queue_addr_lo, while the firmware expects the physical address obtained from the corresponding peer’s queue descriptor. Fix it by filling peer's queue descriptor's physical address in queue_addr_lo. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240520070045.631029-4-quic_ppranees@quicinc.com Signed-off-by: Sasha Levin commit 36fc66a7d9ca3e5c6eac25362cac63f83df8bed6 Author: P Praneesh Date: Mon May 20 12:30:44 2024 +0530 wifi: ath12k: fix invalid memory access while processing fragmented packets [ Upstream commit 073f9f249eecd64ab9d59c91c4a23cfdcc02afe4 ] The monitor ring and the reo reinject ring share the same ring mask index. When the driver receives an interrupt for the reo reinject ring, the monitor ring is also processed, leading to invalid memory access. Since monitor support is not yet enabled in ath12k, the ring mask for the monitor ring should be removed. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240520070045.631029-3-quic_ppranees@quicinc.com Signed-off-by: Sasha Levin commit 6925320fcd40d8042d32bf4ede8248e7a5315c3b Author: P Praneesh Date: Mon May 20 12:30:43 2024 +0530 wifi: ath12k: change DMA direction while mapping reinjected packets [ Upstream commit 33322e3ef07409278a18c6919c448e369d66a18e ] For fragmented packets, ath12k reassembles each fragment as a normal packet and then reinjects it into HW ring. In this case, the DMA direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise, an invalid payload may be reinjected into the HW and subsequently delivered to the host. Given that arbitrary memory can be allocated to the skb buffer, knowledge about the data contained in the reinjected buffer is lacking. Consequently, there’s a risk of private information being leaked. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Co-developed-by: Baochen Qiang Signed-off-by: Baochen Qiang Signed-off-by: P Praneesh Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240520070045.631029-2-quic_ppranees@quicinc.com Signed-off-by: Sasha Levin commit 59423af36b2533665d43eb73971d12271c6ad374 Author: Baochen Qiang Date: Tue May 21 11:08:11 2024 +0300 wifi: ath11k: restore country code during resume [ Upstream commit 7f0343b7b8710436c1e6355c71782d32ada47e0c ] We got report that regdomain is not correct after return from hibernation: Before hibernation: % iw reg get [...] phy#0 (self-managed) country CH: DFS-ETSI (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW (5590 - 5650 @ 40), (N/A, 30), (600000 ms), DFS, AUTO-BW (5650 - 5730 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW (5735 - 5875 @ 80), (N/A, 14), (N/A), AUTO-BW After hibernation: % iw reg get [...] phy#0 (self-managed) country na: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), PASSIVE-SCAN (5170 - 5330 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5735 - 5895 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5945 - 7125 @ 160), (N/A, 30), (N/A), AUTO-BW, PASSIVE-SCAN The reason is, during resume, firmware is reinitialized but host does not send current country code to firmware. So default reg rules with country code set to 'na' is uploaded to host, as shown above. Fix it by restoring country code to firmware during resume. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Fixes: 166a490f59ac ("wifi: ath11k: support hibernation") Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://msgid.link/20240520024148.5472-3-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit bee1f0e97cea5d94abeaccef839ed46eccc9fa5d Author: Baochen Qiang Date: Tue May 21 11:08:10 2024 +0300 wifi: ath11k: refactor setting country code logic [ Upstream commit b363614c0c80f9e2f3ffe8e77270e783a0fb8ab5 ] ath11k_wmi_send_set_current_country_cmd() is called in several places and all of them are just simply repeating the same logic. Refactor to make code clean. Compile tested only. Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://msgid.link/20240520024148.5472-2-quic_bqiang@quicinc.com Stable-dep-of: 7f0343b7b871 ("wifi: ath11k: restore country code during resume") Signed-off-by: Sasha Levin commit 12e0c7822a5a417b0b8154e2540b1880582e4a02 Author: Johannes Berg Date: Mon May 6 21:18:59 2024 +0200 wifi: mac80211: reset negotiated TTLM on disconnect [ Upstream commit 609c12a2af046c3674af2d5c7978b025718de5e8 ] The negotiated TTLM data must be reset on disconnect, otherwise it may end up getting reused on another connection. Fix that. Fixes: 8f500fbc6c65 ("wifi: mac80211: process and save negotiated TID to Link mapping request") Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240506211858.04142e8fe01c.Ia144457e086ebd8ddcfa31bdf5ff210b4b351c22@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d28e8958fc080510e0ce418178a3892f51edac60 Author: Johannes Berg Date: Mon May 6 21:10:34 2024 +0200 wifi: mac80211: cancel TTLM teardown work earlier [ Upstream commit 3567bd6dcd1467d2ad0f597be94114c6f9c62680 ] It shouldn't be possible to run this after disconnecting, so cancel the work earlier. Fixes: a17a58ad2ff2 ("wifi: mac80211: add support for tearing down negotiated TTLM") Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240506211034.096a10ccebec.I5584a21c27eb9b3e87b9e26380b627114b32ccba@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a82d97b9979bf0505cf8a872a4f1b6b2dd667d98 Author: Johannes Berg Date: Mon May 6 21:10:33 2024 +0200 wifi: mac80211: cancel multi-link reconf work on disconnect [ Upstream commit 53b739fd46462dc40fd18390d76f2ee05c18ea3a ] This work shouldn't run after we're disconnecting. Cancel it earlier (and then don't cancel it in stop later.) Fixes: 8eb8dd2ffbbb ("wifi: mac80211: Support link removal using Reconfiguration ML element") Reviewed-by: Ilan Peer Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240506211034.ac754794279f.Ib9fbb1dab50c6b67f6de9be09a6c452ce89bbd50@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9750899410c8478ef043c42029f4f6144c096eac Author: Johannes Berg Date: Mon May 6 21:18:52 2024 +0200 wifi: mac80211: fix TTLM teardown work [ Upstream commit 2fe0a605d083b884490ee4de02be071b5b4291b1 ] The worker calculates the wrong sdata pointer, so if it ever runs, it'll crash. Fix that. Fixes: a17a58ad2ff2 ("wifi: mac80211: add support for tearing down negotiated TTLM") Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240506211853.e6471800c76d.I8b7c2d6984c89a11cd33d1a610e9645fa965f6e1@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 0b336e37e77cb88d605c4143e2f6f9c574eef1d9 Author: Miri Korenblit Date: Sun May 12 15:24:59 2024 +0300 wifi: iwlwifi: mvm: don't skip link selection [ Upstream commit 46144103ace2863e26f4e911aa45200753b7dbca ] If we exit EMLSR due to a IWL_MVM_ESR_EXIT*, a MLO scan followed by a link selection is scheduled with a delay of 30 seconds. If during that 30 seconds EMLSR was blocked and unblocked (IWL_MVM_ESR_BLOCKED*), we would still want to get the needed data from the MLO scan and select link accordingly, and not return immediately to EMLSR. Fixes: 2f33561ea8f9 ("wifi: iwlwifi: mvm: trigger link selection after exiting EMLSR") Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://msgid.link/20240512152312.caab27a8dd8f.I63f67e213d5e05416f71513a8d914917d59aa44f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b17b8b492764a9f69ed0a42514bb1f94b12499f8 Author: Hagar Hemdan Date: Sat May 18 13:04:39 2024 +0000 net: esp: cleanup esp_output_tail_tcp() in case of unsupported ESPINTCP [ Upstream commit 96f887a612e4cda89efc3f54bc10c1997e3ab0e9 ] xmit() functions should consume skb or return error codes in error paths. When the configuration "CONFIG_INET_ESPINTCP" is not set, the implementation of the function "esp_output_tail_tcp" violates this rule. The function frees the skb and returns the error code. This change removes the kfree_skb from both functions, for both esp4 and esp6. WARN_ON is added because esp_output_tail_tcp() should never be called if CONFIG_INET_ESPINTCP is not set. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: e27cca96cd68 ("xfrm: add espintcp (RFC 8229)") Signed-off-by: Hagar Hemdan Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 9a340fe1b0b4e9ccc596ed7c7249c54b3c6e954d Author: Ping-Ke Shih Date: Fri May 17 09:35:43 2024 +0800 wifi: rtw89: 8852b: restore setting for RFE type 5 after device resume [ Upstream commit 2c1fc7c24cd47396580c5a7b238673da618aeedd ] The RFE type 5 set SPS analog parameters only once at probe stage, but the setting is missing after suspend/resume, so remove restriction and set the value when card power on/off. Fixes: 3ef60f44830a ("wifi: rtw89: 8852b: update hardware parameters for RFE type 5") Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240517013543.11533-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit eab9ecfa8ed3da7fe724ce5516948d116fdbc481 Author: Geliang Tang Date: Fri May 17 14:21:46 2024 +0800 selftests/bpf: Fix prog numbers in test_sockmap [ Upstream commit 6c8d7598dfed759bf1d9d0322b4c2b42eb7252d8 ] bpf_prog5 and bpf_prog7 are removed from progs/test_sockmap_kern.h in commit d79a32129b21 ("bpf: Selftests, remove prints from sockmap tests"), now there are only 9 progs in it, not 11: SEC("sk_skb1") int bpf_prog1(struct __sk_buff *skb) SEC("sk_skb2") int bpf_prog2(struct __sk_buff *skb) SEC("sk_skb3") int bpf_prog3(struct __sk_buff *skb) SEC("sockops") int bpf_sockmap(struct bpf_sock_ops *skops) SEC("sk_msg1") int bpf_prog4(struct sk_msg_md *msg) SEC("sk_msg2") int bpf_prog6(struct sk_msg_md *msg) SEC("sk_msg3") int bpf_prog8(struct sk_msg_md *msg) SEC("sk_msg4") int bpf_prog9(struct sk_msg_md *msg) SEC("sk_msg5") int bpf_prog10(struct sk_msg_md *msg) This patch updates the array sizes of prog_fd[], prog_attach_type[] and prog_type[] from 11 to 9 accordingly. Fixes: d79a32129b21 ("bpf: Selftests, remove prints from sockmap tests") Signed-off-by: Geliang Tang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/9c10d9f974f07fcb354a43a8eca67acb2fafc587.1715926605.git.tanggeliang@kylinos.cn Signed-off-by: Sasha Levin commit b04566066c0acfa3379bdde7d145bb15541eab31 Author: Ivan Babrou Date: Mon May 20 15:51:49 2024 -0700 bpftool: Un-const bpf_func_info to fix it for llvm 17 and newer [ Upstream commit f4aba3471cfb9ccf69b476463f19b4c50fef6b14 ] LLVM 17 started treating const structs as constants: * https://github.com/llvm/llvm-project/commit/0b2d5b967d98 Combined with pointer laundering via ptr_to_u64, which takes a const ptr, but in reality treats the underlying memory as mutable, this makes clang always pass zero to btf__type_by_id, which breaks full name resolution. Disassembly before (LLVM 16) and after (LLVM 17): - 8b 75 cc mov -0x34(%rbp),%esi - e8 47 8d 02 00 call 3f5b0 + 31 f6 xor %esi,%esi + e8 a9 8c 02 00 call 3f510 It's a bigger project to fix this properly (and a question whether LLVM itself should detect this), but for right now let's just fix bpftool. For more information, see this thread in bpf mailing list: * https://lore.kernel.org/bpf/CABWYdi0ymezpYsQsPv7qzpx2fWuTkoD1-wG1eT-9x-TSREFrQg@mail.gmail.com/T/ Fixes: b662000aff84 ("bpftool: Adding support for BTF program names") Signed-off-by: Ivan Babrou Signed-off-by: Andrii Nakryiko Acked-by: Nick Desaulniers Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20240520225149.5517-1-ivan@cloudflare.com Signed-off-by: Sasha Levin commit 9abf615e1572dbb89abb6a6fb4e5a89272425593 Author: Baochen Qiang Date: Mon May 20 14:58:28 2024 +0300 wifi: ath12k: fix Smatch warnings on ath12k_core_suspend() [ Upstream commit 33370412eced2dc7f81f4324e109d69319cafd82 ] Smatch is throwing below warning: Commit 692921ead832 ("wifi: ath12k: flush all packets before suspend") leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath12k/core.c:58 ath12k_core_suspend() warn: sleeping in atomic context and also gives the reason: drivers/net/wireless/ath/ath12k/core.c 48 int ret, i; 49 50 if (!ab->hw_params->supports_suspend) 51 return -EOPNOTSUPP; 52 53 rcu_read_lock(); ^^^^^^^^^^^^^^^ Disables preemption. 54 for (i = 0; i < ab->num_radios; i++) { 55 ar = ath12k_mac_get_ar_by_pdev_id(ab, i); 56 if (!ar) 57 continue; --> 58 ret = ath12k_mac_wait_tx_complete(ar); ^^^^^^^ Sleeping in atomic context. 59 if (ret) { 60 ath12k_warn(ab, "failed to wait tx complete: %d\n", ret); 61 rcu_read_unlock(); 62 return ret; 63 } 64 } 65 rcu_read_unlock(); But it is weird that no warning on this in run time even with CONFIG_DEBUG_ATOMIC_SLEEP=y. With some debug it is found that this is because: when system goes to suspend, ath12k_mac_op_stop() gets called where then in ath12k_mac_stop() ab->pdevs_active[ar->pdev_idx] is cleared. This results in ath12k_mac_get_ar_by_pdev_id() always returning a NULL ar, and thereby ath12k_mac_wait_tx_complete() never gets a chance to run. Fix it by retrieving ar directly from ab->pdevs[].ar instead of using ath12k_mac_get_ar_by_pdev_id(). Since ab->pdevs[].ar is set at boot time and won't get cleared when suspend, ath12k_mac_wait_tx_complete() won't be skipped. In addition, with ath12k_mac_get_ar_by_pdev_id() removed, rcu_read_lock()/unlock() are not needed any more, so remove them. This also fixes the warning above. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Fixes: 692921ead832 ("wifi: ath12k: flush all packets before suspend") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/ath12k/7a96ca11-80b5-4751-8cfc-fa637f3aa63a@moroto.mountain/ Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240511095045.9623-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit a9ac7d444de51993cfed3e6fae9931d47ad5c898 Author: Nithyanantham Paramasivam Date: Fri May 10 12:34:27 2024 +0530 wifi: ath12k: Fix tx completion ring (WBM2SW) setup failure [ Upstream commit 0ce9ab2785e4e9ca0752390d8e5ab65bd08f0e78 ] We observe intermittent ping failures from the access point (AP) to station (STA) in any mode (AP-STA or Mesh) configured. Specifically, the transmission completion status is not received at tx completion ring id 4 (WBM2SW ring4) for the packets transmitted via TCL DATA ring id 3. This prevents freeing up tx descriptors and leads to buffer exhaustion. Currently, during initialization of the WBM2SW ring, we are directly mapping the ring number to the ring mask to obtain the ring mask group index. This approach is causing setup failures for WBM2SW ring 4. Similarly, during runtime, when receiving incoming transmission completion status, the validation of the ring number by mapping the interrupted ring mask. This is resulting in validation failure. Thereby preventing entry into the completion handler ath12k_dp_tx_completion_handler(). The existing design assumed that the ring numbers would always be sequential and could be directly mapped with the ring mask. However, this assumption does not hold true for WBM2SW ring 4. Therefore, modify the design such that, instead of mapping the ring number, the ring ID is mapped with the ring mask. According to this design: 1. During initialization of the WBM2SW ring, mapping the ring ID to the ring mask will ensure obtaining the correct ring mask group ID. 2. During runtime, validating the interrupted ring mask group ID within the transmission completion group is sufficient. This approach allows the ring ID to be derived from the interrupted ring mask and enables entry into the completion handler. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Nithyanantham Paramasivam Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240510070427.206152-1-quic_nithp@quicinc.com Signed-off-by: Sasha Levin commit 7f41e6f884cc9ec715d8d2ac3a22b3aae0c209f8 Author: Pradeep Kumar Chitrapu Date: Wed May 8 10:36:51 2024 -0700 wifi: ath12k: Correct 6 GHz frequency value in rx status [ Upstream commit c3c84a74bd797f76d7da036c9fef947d674bbc18 ] The frequency in the rx status is currently being filled incorrectly for the 6 GHz band. The channel number received is invalid in this case, resulting in packet drops. Fix this issue by correcting the frequency calculation. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Pradeep Kumar Chitrapu Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240508173655.22191-3-quic_pradeepc@quicinc.com Signed-off-by: Sasha Levin commit c33154cd0e162291a5b8b5db2e1786bfb13c0953 Author: Samasth Norway Ananda Date: Thu May 9 16:10:37 2024 -0700 wifi: brcmsmac: LCN PHY code is used for BCM4313 2G-only device [ Upstream commit c636fa85feb450ca414a10010ed05361a73c93a6 ] The band_idx variable in the function wlc_lcnphy_tx_iqlo_cal() will never be set to 1 as BCM4313 is the only device for which the LCN PHY code is used. This is a 2G-only device. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Signed-off-by: Samasth Norway Ananda Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://msgid.link/20240509231037.2014109-1-samasth.norway.ananda@oracle.com Signed-off-by: Sasha Levin commit c9a04fc4596778c90cb6eac82afcbed2f0b3637f Author: Kang Yang Date: Mon Apr 29 16:15:22 2024 +0800 wifi: ath12k: avoid duplicated vdev stop [ Upstream commit 3b0989e925f38df733a03ff5a320d6841006b3f9 ] ath12k_mac_op_unassign_vif_chanctx() will do vdev stop in ath12k_mac_monitor_stop(). This ath12k_mac_vdev_stop() will do vdev stop again, then might trigger firmware crash. So add judgement to avoid duplicated vdev stop. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: c9e4e41e71ff ("wifi: ath12k: move peer delete after vdev stop of station for WCN7850") Signed-off-by: Kang Yang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240429081525.983-3-quic_kangyang@quicinc.com Signed-off-by: Sasha Levin commit e0f67630ee8f632fa762f81e42afe79d37e9bc1f Author: Karthikeyan Kathirvel Date: Fri May 3 13:34:39 2024 +0300 wifi: ath12k: drop failed transmitted frames from metric calculation. [ Upstream commit 50971dc6694c0845fcddfe337ea39c5b723d5a92 ] In mesh node traffic, internal firmware-transmitted failures are reported as transmitted failures in mesh metric calculation, leading to the breakage of the mesh link. Fix the issue by dropping the internal firmware-transmitted failures before updating the TX completion status to mac80211, in order to prevent false failure averaging in mesh metric calculation. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Karthikeyan Kathirvel Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240430074313.885807-3-quic_kathirve@quicinc.com Signed-off-by: Sasha Levin commit 059ef22f55ee005790a4ad8e8c02220553bd73d1 Author: Sven Eckelmann Date: Fri May 3 13:34:39 2024 +0300 wifi: ath12k: Don't drop tx_status in failure case [ Upstream commit 5453bbd6fef4ca2fea3b4b338fc715d7135afc6f ] When a station idles for a long time, hostapd will try to send a QoS Null frame to the station as "poll". NL80211_CMD_PROBE_CLIENT is used for this purpose. And the skb will be added to ack_status_frame - waiting for a completion via ieee80211_report_ack_skb(). But when the peer was already removed before the tx_complete arrives, the peer will be missing. And when using dev_kfree_skb_any (instead of going through mac80211), the entry will stay inside ack_status_frames thus not clean up related information in its internal data structures. This IDR will therefore run full after 8K request were generated for such clients. At this point, the access point will then just stall and not allow any new clients because idr_alloc() for ack_status_frame will fail. ieee80211_free_txskb() on the other hand will (when required) call ieee80211_report_ack_skb() and make sure that (when required) remove the entry from the ack_status_frame and clean up related information in its internal data structures. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sven Eckelmann Signed-off-by: Sarika Sharma Signed-off-by: Karthikeyan Kathirvel Link: https://lore.kernel.org/r/20230802-ath11k-ack_status_leak-v2-1-c0af729d6229@narfation.org Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240430074313.885807-2-quic_kathirve@quicinc.com Signed-off-by: Sasha Levin commit 2af312f4a6d03810bae682c63fdf04ee7dfd2668 Author: Marek Behún Date: Mon Jul 15 13:59:12 2024 +0200 firmware: turris-mox-rwtm: Initialize completion before mailbox [ Upstream commit 49e24c80d3c81c43e2a56101449e1eea32fcf292 ] Initialize the completion before the mailbox channel is requested. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún Reviewed-by: Andy Shevchenko Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 4f3811ecac84aa0c850d0b5f364a68bc5874387c Author: Marek Behún Date: Mon Jul 15 13:59:11 2024 +0200 firmware: turris-mox-rwtm: Fix checking return value of wait_for_completion_timeout() [ Upstream commit 8467cfe821ac3526f7598682ad5f90689fa8cc49 ] The wait_for_completion_timeout() function returns 0 if timed out, and a positive value if completed. Fix the usage of this function. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Fixes: 2eab59cf0d20 ("firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng") Signed-off-by: Marek Behún Reviewed-by: Ilpo Järvinen Reviewed-by: Andy Shevchenko Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit c83d61d3cab0a95ef7b5336979d98300ee4b3b94 Author: Marek Behún Date: Mon Jul 15 13:59:10 2024 +0200 firmware: turris-mox-rwtm: Do not complete if there are no waiters [ Upstream commit 0bafb172b111ab27251af0eb684e7bde9570ce4c ] Do not complete the "command done" completion if there are no waiters. This can happen if a wait_for_completion() timed out or was interrupted. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún Reviewed-by: Andy Shevchenko Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 1081b3f819610b11c78246555b0a83c4e456e80b Author: Christophe Leroy Date: Fri Jul 12 07:51:58 2024 +0200 vmlinux.lds.h: catch .bss..L* sections into BSS") [ Upstream commit 1a7b7326d587c9a5e8ff067e70d6aaf0333f4bb3 ] Commit 9a427556fb8e ("vmlinux.lds.h: catch compound literals into data and BSS") added catches for .data..L* and .rodata..L* but missed .bss..L* Since commit 5431fdd2c181 ("ptrace: Convert ptrace_attach() to use lock guards") the following appears at build: LD .tmp_vmlinux.kallsyms1 powerpc64-linux-ld: warning: orphan section `.bss..Lubsan_data33' from `kernel/ptrace.o' being placed in section `.bss..Lubsan_data33' NM .tmp_vmlinux.kallsyms1.syms KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 powerpc64-linux-ld: warning: orphan section `.bss..Lubsan_data33' from `kernel/ptrace.o' being placed in section `.bss..Lubsan_data33' NM .tmp_vmlinux.kallsyms2.syms KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux powerpc64-linux-ld: warning: orphan section `.bss..Lubsan_data33' from `kernel/ptrace.o' being placed in section `.bss..Lubsan_data33' Lets add .bss..L* to BSS_MAIN macro to catch those sections into BSS. Fixes: 9a427556fb8e ("vmlinux.lds.h: catch compound literals into data and BSS") Signed-off-by: Christophe Leroy Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404031349.nmKhyuUG-lkp@intel.com/ Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 3dc633cb63305fd9b60fd9a8546cf9208748fd56 Author: Tom Lendacky Date: Fri Jun 21 10:42:05 2024 -0500 x86/sev: Do RMP memory coverage check after max_pfn has been set [ Upstream commit 0440feb090790c6243bca85d6a794824e71ff26c ] The RMP table is probed early in the boot process before max_pfn has been set, so the logic to check if the RMP covers all of system memory is not valid. Move the RMP memory coverage check from snp_probe_rmptable_info() into snp_rmptable_init(), which is well after max_pfn has been set. Also, fix the calculation to use PFN_UP instead of PHYS_PFN, in order to compute the required RMP size properly. Fixes: 216d106c7ff7 ("x86/sev: Add SEV-SNP host initialization support") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/bec4364c7e34358cc576f01bb197a7796a109169.1718984524.git.thomas.lendacky@amd.com Signed-off-by: Sasha Levin commit 8057117dafb49e8caf6a4b0f36856182abcb2e70 Author: Yanjun Yang Date: Tue Jun 11 18:09:47 2024 +0800 ARM: Remove address checking for MMUless devices [ Upstream commit 3ccea4784fddd96fbd6c4497eb28b45dab638c2a ] Commit 169f9102f9198b ("ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()") added the function to check address before use. However, for devices without MMU, addr > TASK_SIZE will always fail. This patch move this function after the #ifdef CONFIG_MMU statement. Signed-off-by: Yanjun Yang Acked-by: Ard Biesheuvel Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218953 Fixes: 169f9102f9198b ("ARM: 9350/1: fault: Implement copy_from_kernel_nofault_allowed()") Link: https://lore.kernel.org/r/20240611100947.32241-1-yangyj.ee@gmail.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 38908feafa26af60dc4e80404b0391a90005dea3 Author: Dmitry Torokhov Date: Fri Jun 28 11:08:41 2024 -0700 ARM: spitz: fix GPIO assignment for backlight [ Upstream commit 78ab3d352f2982bf3f7e506bfbaba7afee1ed8a9 ] GPIOs controlling backlight on Spitz and Akita are coming from GPIO expanders, not the pxa27xx-gpio block, correct it. Additionally GPIO lookup tables operate with pin numbers rather than legacy GPIO numbers, fix that as well. Use raw numbers instead of legacy GPIO names to avoid confusion. Fixes: ee0c8e494cc3 ("backlight: corgi: Convert to use GPIO descriptors") Reviewed-by: Linus Walleij Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20240628180852.1738922-2-dmitry.torokhov@gmail.com Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 50162623cb8da7f55c20a3871e103a9582667ccd Author: Thorsten Blum Date: Tue Jul 2 05:41:17 2024 +0200 m68k: cmpxchg: Fix return value for default case in __arch_xchg() [ Upstream commit 21b9e722ad28c19c2bc83f18f540b3dbd89bf762 ] The return value of __invalid_xchg_size() is assigned to tmp instead of the return variable x. Assign it to x instead. Fixes: 2501cf768e4009a0 ("m68k: Fix xchg/cmpxchg to fail to link if given an inappropriate pointer") Signed-off-by: Thorsten Blum Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20240702034116.140234-2-thorsten.blum@toblux.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 57a818bfa03b1e6fcef663e3f256869eb5ee4668 Author: Dhananjay Ugwekar Date: Tue Jul 2 08:14:14 2024 +0000 cpufreq/amd-pstate: Fix the scaling_max_freq setting on shared memory CPPC systems [ Upstream commit 738d7d03571c7e38565bd245c0815a2c74665018 ] On shared memory CPPC systems, with amd_pstate=active mode, the change in scaling_max_freq doesn't get written to the shared memory region. Due to this, the writes to the scaling_max_freq sysfs file don't take effect. Fix this by propagating the scaling_max_freq changes to the shared memory region. Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Reported-by: David Arcari Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20240702081413.5688-3-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit aff58cd5ddc1a98e16d5cf1fe41e77b462511dba Author: Dhananjay Ugwekar Date: Tue Jul 2 08:14:13 2024 +0000 cpufreq/amd-pstate-ut: Convert nominal_freq to khz during comparisons [ Upstream commit f21ab5ed4e8758b06230900f44b9dcbcfdc0c3ae ] cpudata->nominal_freq being in MHz whereas other frequencies being in KHz breaks the amd-pstate-ut frequency sanity check. This fixes it. Fixes: e4731baaf294 ("cpufreq: amd-pstate: Fix the inconsistency in max frequency units") Reported-by: David Arcari Signed-off-by: Dhananjay Ugwekar Reviewed-by: Mario Limonciello Reviewed-by: Gautham R. Shenoy Link: https://lore.kernel.org/r/20240702081413.5688-2-Dhananjay.Ugwekar@amd.com Signed-off-by: Mario Limonciello Signed-off-by: Sasha Levin commit d7a8cf3fafc44ff01a7136cdc7c2ddacf4b87c29 Author: Luca Weiss Date: Fri Jul 5 09:43:11 2024 +0200 arm64: dts: qcom: sm6350: Add missing qcom,non-secure-domain property [ Upstream commit 81008068ee4f2c4c26e97a0404405bb4b450241b ] By default the DSP domains are secure, add the missing qcom,non-secure-domain property to mark them as non-secure. Fixes: efc33c969f23 ("arm64: dts: qcom: sm6350: Add ADSP nodes") Fixes: 8eb5287e8a42 ("arm64: dts: qcom: sm6350: Add CDSP nodes") Reviewed-by: Dmitry Baryshkov Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20240705-sm6350-fastrpc-fix-v2-1-89a43166c9bb@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9633f16563c2524e99dc42469a5cceb7aeb25da7 Author: Chukun Pan Date: Sun Jun 30 23:00:07 2024 +0800 arm64: dts: rockchip: fixes PHY reset for Lunzn Fastrhino R68S [ Upstream commit e261bd74000ca80e5483ba8a8bda509de8cbe7fd ] Fixed the PHY address and reset GPIOs (does not match the corresponding pinctrl) for gmac0 and gmac1. Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240630150010.55729-7-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9a19c4a67e5e82f1c16b094a0f61d7bd6bda32a5 Author: Chukun Pan Date: Mon Jul 1 22:30:27 2024 +0800 arm64: dts: rockchip: disable display subsystem for Lunzn Fastrhino R6xS [ Upstream commit 2bf5d445df2ec89689d15ea259a916260c936959 ] The R66S and R68S boards do not have HDMI output, so disable the display subsystem. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240701143028.1203997-3-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 4f19bf7f6d6d79d7e906cd6b7322255129f1e0ea Author: Chukun Pan Date: Sun Jun 30 23:00:05 2024 +0800 arm64: dts: rockchip: remove unused usb2 nodes for Lunzn Fastrhino R6xS [ Upstream commit cd77139a307fbabe75e6b5cb8a3753e3c700f394 ] Fix the following error when booting: [ 15.851853] platform fd800000.usb: deferred probe pending [ 15.852384] platform fd840000.usb: deferred probe pending [ 15.852881] platform fd880000.usb: deferred probe pending This is due to usb2phy1 is not enabled. There is no USB 2.0 port on the board, just remove it. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240630150010.55729-5-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit e22a93c8070d9b89a9abccd377a5a4e02da25a47 Author: Chukun Pan Date: Sun Jun 30 23:00:04 2024 +0800 arm64: dts: rockchip: fix pmu_io supply for Lunzn Fastrhino R6xS [ Upstream commit cfeac8e5d05815521f5c5568680735a92ee91fe4 ] Fixes pmu_io_domains supply according to the schematic. Among them, the vccio3 is responsible for the io voltage of sdcard. There is no sdcard slot on the R68S, and it's connected to vcc_3v3, so describe the supply of vccio3 separately. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Fixes: b9f8ca655d80 ("arm64: dts: rockchip: Add Lunzn Fastrhino R68S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240630150010.55729-4-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 65de64c52ce03d1b8ae399f6846d5f02a07052d1 Author: Chukun Pan Date: Mon Jul 1 22:30:26 2024 +0800 arm64: dts: rockchip: fix usb regulator for Lunzn Fastrhino R6xS [ Upstream commit 9e823ba92118510c0d1c050b67bb000f9b9a73d7 ] Remove the non-existent usb_host regulator and fix the supply according to the schematic. Also remove the unnecessary always-on and boot-on for the usb_otg regulator. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240701143028.1203997-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 36f12ac15e6cb3517a53d5ec48defeddcdd851d7 Author: Chukun Pan Date: Sun Jun 30 23:00:02 2024 +0800 arm64: dts: rockchip: fix regulator name for Lunzn Fastrhino R6xS [ Upstream commit 2dad31528de9ea8b05245ce6ac4f76ebf8dae947 ] Make the regulator name the same as those marked by schematics. Fixes: c79dab407afd ("arm64: dts: rockchip: Add Lunzn Fastrhino R66S") Signed-off-by: Chukun Pan Link: https://lore.kernel.org/r/20240630150010.55729-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 66dbed68402654e9755b77604cfdcd671e5b2683 Author: Cristian Ciocaltea Date: Tue Jul 2 04:12:52 2024 +0300 arm64: dts: rockchip: Add missing power-domains for rk356x vop_mmu [ Upstream commit 9d42c3ee3ce37cdad6f98c9e77bfbd0d791ac7da ] The iommu@fe043e00 on RK356x SoC shares the VOP power domain, but the power-domains property was not provided when the node has been added. The consequence is that an attempt to reload the rockchipdrm module will freeze the entire system. That is because on probe time, pm_runtime_get_suppliers() gets called for vop@fe040000, which blocks when pm_runtime_get_sync() is being invoked for iommu@fe043e00. Fix the issue by adding the missing property. Fixes: 9d6c6d978f97 ("arm64: dts: rockchip: rk356x: Add VOP2 nodes") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20240702-rk356x-fix-vop-mmu-v1-1-a66d1a0c45ea@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 1709d8fc48e19e6d481d1616aa72a8b00f951087 Author: Dang Huynh Date: Tue Jul 2 13:01:19 2024 +0700 arm64: dts: qcom: qrb4210-rb2: Correct max current draw for VBUS [ Upstream commit c6050d45cd372e4a34f9f501b30243caf2e810c6 ] According to downstream sources, maximum current for PMI632 VBUS is 1A. Taken from msm-4.19 (631561973a034e46ccacd0e53ef65d13a40d87a4) Line 685-687 in drivers/power/supply/qcom/qpnp-smb5.c Fixes: a06a2f12f9e2 ("arm64: dts: qcom: qrb4210-rb2: enable USB-C port handling") Reviewed-by: Luca Weiss Signed-off-by: Dang Huynh Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240702-qrd4210rb2-vbus-volt-v3-1-fbd24661eec4@riseup.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit eaf36e6600fa4621f124f4d1a92cd402263219b5 Author: Chen Ni Date: Tue Jul 2 11:10:10 2024 +0800 x86/xen: Convert comma to semicolon [ Upstream commit 349d271416c61f82b853336509b1d0dc04c1fcbb ] Replace a comma between expression statements by a semicolon. Fixes: 8310b77b48c5 ("Xen/gnttab: handle p2m update errors on a per-slot basis") Signed-off-by: Chen Ni Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20240702031010.1411875-1-nichen@iscas.ac.cn Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit cba20cbcf31b32c551fdf7345c99b94b6df17d3c Author: Abel Vesa Date: Sat Jun 29 09:29:43 2024 +0300 arm64: dts: qcom: x1e80100: Fix USB HS PHY 0.8V supply [ Upstream commit 9c99c33a904c86d95ecf4e2690de6a826b88671c ] According to the power grid documentation, the 0.8v HS PHY shared regulator is actually LDO3 from PM8550ve id J. Fix both CRD and QCP boards. Fixes: d7e03cce0400 ("arm64: dts: qcom: x1e80100-crd: Enable more support") Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240629-x1e80100-dts-fix-hsphy-0-8v-supplies-v1-1-de99ee030b27@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d437ba496d2c41c77f700aa0cdf19ee8616e381b Author: Adam Ford Date: Wed Jun 19 05:10:44 2024 -0500 arm64: dts: imx8mp: Fix pgc vpu locations [ Upstream commit 2f8405fb077bcb8e98c8cd87c2a0a238b15d8da8 ] The various pgv_vpu nodes have a mismatch between the value after the @ symbol and what is referenced by 'reg' so reorder the nodes to align. Fixes: df680992dd62 ("arm64: dts: imx8mp: add vpu pgc nodes") Suggested-by: Alexander Stein Signed-off-by: Adam Ford Reviewd-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4bf10cc8b52100e2769756fe3dcf93c287fd4f13 Author: Adam Ford Date: Mon Jun 17 17:39:51 2024 -0500 arm64: dts: imx8mp: Fix pgc_mlmix location [ Upstream commit 106f68fc9da3d4835070b55a2229d2c54ef5cba1 ] The pgc_mlmix shows a power-domain@24, but the reg value is IMX8MP_POWER_DOMAIN_MLMIX which is set to 4. The stuff after the @ symbol should match the stuff referenced by 'reg' so reorder the pgc_mlmix so it to appear as power-domain@4. Fixes: 834464c8504c ("arm64: dts: imx8mp: add mlmix power domain") Fixes: 4bedc468b725 ("arm64: dts: imx8mp: Add NPU Node") Signed-off-by: Adam Ford Reviewed-by: Peng Fan Reviewed-by: Marek Vasut Reviewed-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 92df560733f7debe41328dc4893a631898e382ae Author: Eero Tamminen Date: Mon Jun 24 17:49:01 2024 +0300 m68k: atari: Fix TT bootup freeze / unexpected (SCU) interrupt messages [ Upstream commit f70065a9fd988983b2c693631b801f25a615fc04 ] Avoid freeze on Atari TT / MegaSTe boot with continuous messages of: unexpected interrupt from 112 Which was due to VBL interrupt being enabled in SCU sys mask, but there being no handler for that any more. (Bug and fix were first verified on real Atari TT HW by Christian, this patch later on in Hatari emulator.) Fixes: 1fa0b29f3a43f9dd ("fbdev: Kill Atari vblank cursor blinking") Reported-by: Nicolas Pomarède Closes: https://listengine.tuxfamily.org/lists.tuxfamily.org/hatari-devel/2024/06/msg00016.html Closes: https://lore.kernel.org/all/9aa793d7-82ed-4fbd-bce5-60810d8a9119@helsinkinet.fi Tested-by: Christian Zietz Signed-off-by: Eero Tamminen Reviewed-by: Michael Schmitz Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20240624144901.5236-1-oak@helsinkinet.fi Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 4bc7267967cdac0e77b57bfd2c4c16b15f3b4747 Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:37 2024 +0200 arm64: dts: renesas: r9a08g045: Add missing hypervisor virtual timer IRQ [ Upstream commit 10f9badc473d43ebfddd1ddedbcb8eb3f8f3fdd9 ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: e20396d65b959a65 ("arm64: dts: renesas: Add initial DTSI for RZ/G3S SoC") Signed-off-by: Geert Uytterhoeven Reviewed-by: Claudiu Beznea Tested-by: Claudiu Beznea Link: https://lore.kernel.org/884c683fb6c1d1bf7d0d383a8df8f65a0a424dc7.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 2eee24dbb952ff784390ba1d1a3e1791edecf7f7 Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:36 2024 +0200 arm64: dts: renesas: r9a07g054: Add missing hypervisor virtual timer IRQ [ Upstream commit 2918674704aad620215c41979a331021fe3f1ec4 ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: 7c2b8198f4f321df ("arm64: dts: renesas: Add initial DTSI for RZ/V2L SoC") Signed-off-by: Geert Uytterhoeven Reviewed-by: Lad Prabhakar Link: https://lore.kernel.org/834244e77e5f407ee6fab1ab5c10c98a8a933085.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit e88370be243cde2acfe749195fb280c544ac5edf Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:35 2024 +0200 arm64: dts: renesas: r9a07g044: Add missing hypervisor virtual timer IRQ [ Upstream commit ecbc5206a1a0532258144a4703cccf4e70f3fe6c ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: 68a45525297b2e9a ("arm64: dts: renesas: Add initial DTSI for RZ/G2{L,LC} SoC's") Signed-off-by: Geert Uytterhoeven Reviewed-by: Lad Prabhakar Link: https://lore.kernel.org/21f556eb7e903d5b9f4c96188fd4b6ae0db71856.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit c34ac879e17ff98ede32a34bc559d50983f6c922 Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:34 2024 +0200 arm64: dts: renesas: r9a07g043u: Add missing hypervisor virtual timer IRQ [ Upstream commit 4036bae6dfd782d414040e7d714abc525b2e8792 ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: cf40c9689e5109bf ("arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC") Signed-off-by: Geert Uytterhoeven Reviewed-by: Lad Prabhakar Link: https://lore.kernel.org/15cc7a7522b1658327a2bd0c4990d0131bbcb4d7.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 94f19d09e81eab70777af75654a647bdb4d665b8 Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:33 2024 +0200 arm64: dts: renesas: r8a779g0: Add missing hypervisor virtual timer IRQ [ Upstream commit 6775165fc95052a03acc91e25bc20fcf286910a7 ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: 987da486d84a5643 ("arm64: dts: renesas: Add Renesas R8A779G0 SoC support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/5eeabbeaea1c5fd518a608f2e8013d260b00fd7e.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit d5c33c9ed99cdcb48edb635a44ecab880c6afbda Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:32 2024 +0200 arm64: dts: renesas: r8a779f0: Add missing hypervisor virtual timer IRQ [ Upstream commit b1c34567aebe300f9a0f70320eaeef0b3d56ffc7 ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: c62331e8222f8f21 ("arm64: dts: renesas: Add Renesas R8A779F0 SoC support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/46deba1008f73e4b6864f937642d17f9d4ae7205.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 703eedeebe139473065c83e5478f14d338d3900c Author: Geert Uytterhoeven Date: Thu Jun 20 15:57:31 2024 +0200 arm64: dts: renesas: r8a779a0: Add missing hypervisor virtual timer IRQ [ Upstream commit 6fca24a07e1de664c3d0b280043302e0387726df ] Add the missing fifth interrupt to the device node that represents the ARM architected timer. While at it, add an interrupt-names property for clarity, Fixes: 834c310f541839b6 ("arm64: dts: renesas: Add Renesas R8A779A0 SoC support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/671416fb31e3992101c32fe7e46147fe4cd623ae.1718890849.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 68e39a9a7f7170564b0add0e25913fa27441ed10 Author: Geert Uytterhoeven Date: Thu Jun 20 15:38:45 2024 +0200 arm64: dts: renesas: r8a779h0: Drop "opp-shared" from opp-table-0 [ Upstream commit f3acb237a17962349b61eed813f62dddf7aead29 ] The four Cortex-A76 CPU cores on R-Car V4M share their Operating Performance Points (OPP) table, but they have independent clocks. All cores in the cluster can switch DVFS states independently, hence the cluster's OPP table should not have an "opp-shared" property. Fixes: 6bd8b0bc444eae56 ("arm64: dts: renesas: r8a779h0: Add CA76 operating points") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/4e0227ff4388485cdb1ca2855ee6df92754e756e.1718890585.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 30c59704ab60f7098bf3d97ad566d5a1fcb9ae9f Author: Cristian Ciocaltea Date: Sat Jun 22 00:57:22 2024 +0300 arm64: dts: rockchip: Fix mic-in-differential usage on rk3568-evb1-v10 [ Upstream commit ec03073888ad23223ebb986e62583c20a9ed3c07 ] The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dtb rk3568-evb1-v10.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# Make use of the correct property name. Fixes: 3e4c629ca680 ("arm64: dts: rockchip: enable rk809 audio codec on the rk3568 evb1-v10") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-5-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit d65388253c1aa8e31cb665d21e84d75271f623a2 Author: Cristian Ciocaltea Date: Sat Jun 22 00:57:21 2024 +0300 arm64: dts: rockchip: Fix mic-in-differential usage on rk3566-roc-pc [ Upstream commit e643e4eb4bef6a2f95bf0c61a20c991bccecb212 ] The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dtb rk3566-roc-pc.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# Make use of the correct property name. Fixes: a8e35c4bebe4 ("arm64: dts: rockchip: add audio nodes to rk3566-roc-pc") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-4-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit c9d4cbc72a4696eb59e5c49e5024036447ec0179 Author: Cristian Ciocaltea Date: Sat Jun 22 00:57:20 2024 +0300 arm64: dts: rockchip: Drop invalid mic-in-differential on rk3568-rock-3a [ Upstream commit 406a554b382200abfabd1df423a425f6efee53e0 ] The 'mic-in-differential' DT property supported by the RK809/RK817 audio codec driver is actually valid if prefixed with 'rockchip,': DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dtb rk3568-rock-3a.dtb: pmic@20: codec: 'mic-in-differential' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# However, the board doesn't make use of differential signaling, hence drop the incorrect property and the now unnecessary 'codec' node. Fixes: 22a442e6586c ("arm64: dts: rockchip: add basic dts for the radxa rock3 model a") Reported-by: Jonas Karlman Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20240622-rk809-fixes-v2-3-c0db420d3639@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f146001e49922dcef371d1b1a3c09df9d18ff757 Author: Jerome Brunet Date: Wed Jun 26 17:27:31 2024 +0200 arm64: dts: amlogic: setup hdmi system clock [ Upstream commit 1443b6ea806dfcdcee6c894784332c9c947ac319 ] HDMI Tx needs the system clock set on the xtal rate. This clock is managed by the main clock controller of the related SoCs. Currently 2 part of the display drivers race to setup the HDMI system clock by directly poking the controller register. The clock API should be used to setup the rate instead. Use assigned-clock to setup the HDMI system clock. Fixes: 6939db7e0dbf ("ARM64: dts: meson-gx: Add support for HDMI output") Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20240626152733.1350376-3-jbrunet@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 5d1e9ca9f76eeb828053df817d3e58a3df107e10 Author: Jerome Brunet Date: Tue Jun 25 16:50:15 2024 +0200 arm64: dts: amlogic: add power domain to hdmitx [ Upstream commit f1ab099d6591a353899a2ee09c89de0fc908e2d2 ] HDMI Tx needs HDMI Tx memory power domain turned on. This power domain is handled under the VPU power domain. The HDMI Tx currently works because it is enabling the PD by directly poking the power controller register. It is should not do that but properly use the power domain controller. Fix this by adding the power domain to HDMI Tx. Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20240625145017.1003346-3-jbrunet@baylibre.com Signed-off-by: Neil Armstrong Stable-dep-of: 1443b6ea806d ("arm64: dts: amlogic: setup hdmi system clock") Signed-off-by: Sasha Levin commit 70bc57ac4f73b5e6b4bcfea62e36b829de03d9c7 Author: Jerome Brunet Date: Wed Jun 26 17:27:30 2024 +0200 arm64: dts: amlogic: gx: correct hdmi clocks [ Upstream commit 0602ba0dcd0e76067a0b7543e92b2de3fb231073 ] The clocks provided to HDMI tx are not consistent between gx and g12: * gx receives the peripheral clock as 'isfr' while g12 receives it as 'iahb' * g12 gets the HDMI system clock as 'isfr' but gx does not even get it. It surely needs that clock since the driver is directly poking around the clock controller's registers for that clock. Align gx SoCs with g12 and provide: * the HDMI peripheral clock as 'iahb' * the HDMI system clock as 'isfr' Fixes: 6939db7e0dbf ("ARM64: dts: meson-gx: Add support for HDMI output") Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20240626152733.1350376-2-jbrunet@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit e5ed533f690f3436d700a602ebb3cb1b719eb02e Author: AngeloGioacchino Del Regno Date: Wed Jun 19 12:30:34 2024 +0200 soc: mediatek: mtk-mutex: Add MDP_TCC0 mod to MT8188 mutex table [ Upstream commit 161ee1eb9ab2440553dac55ada8329de704b1ffd ] MT8188's MDP3 is able to use MDP_TCC0, this mutex_mod bit does actually exist and it's the same as MT8195: add it to the table. Fixes: 26bb17dae6fa ("soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS") Reviewed-by: Fei Shao Link: https://lore.kernel.org/r/20240619103034.110377-1-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a6a7ed42ac93d42f091faf62f237d22d525629d6 Author: Chen-Yu Tsai Date: Wed Jan 31 16:39:29 2024 +0800 arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add ports node for anx7625 [ Upstream commit 4055416e6c51347e7dd5784065263fe0ced0bb7d ] The anx7625 binding requires a "ports" node as a container for the "port" nodes. The jacuzzi dtsi file is missing it. Add a "ports" node under the anx7625 node, and move the port related nodes and properties under it. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131083931.3970388-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit c0d6ac595e1526100c90713ca97c6b847432f4ee Author: Chen-Yu Tsai Date: Wed Jan 31 16:40:41 2024 +0800 arm64: dts: mediatek: mt8183-pico6: Fix wake-on-X event node names [ Upstream commit 70bf81dd2c2dedbed1f19dfc5d1d2f22474a5296 ] The wake-on-bt and wake-on-wlan nodes don't have a button- or event- prefix that the gpio-keys binding requires. Fix up the node names to satisfy the binding. While at it, also fix up the GPIO overriding structure for the wake-on-wlan node. Instead of referencing the gpio-keys node and then open coding the node, add a label for the event node, and use that to reference and override the GPIO settings. Fixes: 055ef10ccdd4 ("arm64: dts: mt8183: Add jacuzzi pico/pico6 board") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131084043.3970576-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 8bd5cc9b7bfd34e39ff7ac1f6e7a6900fd959458 Author: Hsin-Te Yuan Date: Thu Jun 13 11:58:54 2024 +0000 arm64: dts: mediatek: mt8183-kukui: Fix the value of `dlg,jack-det-rate` mismatch [ Upstream commit 95173af725e6f41eb470466a52ddf2054439409c ] According to Documentation/devicetree/bindings/sound/dialog,da7219.yaml, the value of `dlg,jack-det-rate` property should be "32_64" instead of "32ms_64ms". Fixes: dc0ff0fa3a9b ("ASoC: da7219: Add Jack insertion detection polarity") Signed-off-by: Hsin-Te Yuan Link: https://lore.kernel.org/r/20240613-jack-rate-v2-1-ebc5f9f37931@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 33456268a54e10c88242a9703ee0dcec45b386f7 Author: Rafał Miłecki Date: Tue Jun 4 09:49:16 2024 +0200 arm64: dts: mediatek: mt7622: fix "emmc" pinctrl mux [ Upstream commit aebba1030a5766cdf894ed4ab0cac7aed5aee9c1 ] Value "emmc_rst" is a group name and should be part of the "groups" property. This fixes: arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml# arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: pinctrl@10211000: emmc-pins-default:mux:function: ['emmc', 'emmc_rst'] is too long from schema $id: http://devicetree.org/schemas/pinctrl/mediatek,mt7622-pinctrl.yaml# Fixes: 3725ba3f5574 ("arm64: dts: mt7622: add pinctrl related device nodes") Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board") Signed-off-by: Rafał Miłecki Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240604074916.7929-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a3c80f9326aea4da9be0a59482eb0e4299ca6c82 Author: Rafał Miłecki Date: Fri Apr 5 12:50:30 2024 +0200 arm64: dts: mediatek: mt7981: fix code alignment for PWM clocks [ Upstream commit f80cfe9616b7448eca709a3e87ca57201cd5787c ] Align "clocks" array entries to start at the same column. Fixes: cf29427573cc ("arm64: dts: mediatek: Add initial MT7981B and Xiaomi AX3000T") Signed-off-by: Rafał Miłecki Link: https://lore.kernel.org/r/20240405105030.24559-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit a07456e3c3d0cd1a865ec5e4b1bf37b547c9a928 Author: Pin-yen Lin Date: Thu May 2 23:39:51 2024 +0800 arm64: dts: mediatek: mt8192-asurada: Add off-on-delay-us for pp3300_mipibrdg [ Upstream commit 897a7edba9330974726c564dfdbf4fb5e203b9ac ] Set off-on-delay-us to 500000 us for pp3300_mipibrdg to make sure it complies with the panel's unprepare delay (the time to power down completely) of the power sequence. Explicit configuration on the regulator node is required because mt8192-asurada uses the same power supply for the panel and the anx7625 DP bridge. For example, the power sequence could be violated in this sequence: 1. Bridge on: panel goes off, but regulator doesn't turn off (refcount=1). 2. Bridge off: regulator turns off (refcount=0). 3. Bridge resume -> regulator turns on but the bridge driver doesn't check the delay. Or in this sequence: 1. Bridge on: panel goes off. The regulator doesn't turn off (refcount=1), but the .unprepared_time in panel_edp is still updated. 2. Bridge off, regulator goes off (refcount=0). 3. Panel on, but the panel driver uses the wrong .unprepared_time to check the unprepare delay. Fixes: f9f00b1f6b9b ("arm64: dts: mediatek: asurada: Add display regulators") Signed-off-by: Pin-yen Lin Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240502154455.3427793-1-treapking@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit c42e03a08ba9aaae92f022fc6414f7106cdbb07f Author: Chen-Yu Tsai Date: Fri Apr 12 15:56:12 2024 +0800 arm64: dts: mediatek: mt8183-kukui: Drop bogus output-enable property [ Upstream commit e9a9055fdcdc1e5a27cef118c5b4f09cdd2fa28e ] The "output-enable" property is set on uart1's RTS pin. This is bogus because the hardware does not actually have a controllable output buffer. Secondly, the implementation incorrectly treats this property as a request to switch the pin to GPIO output. This does not fit the intended semantic of "output-enable" and it does not have any affect either because the pin is muxed to the UART function, not the GPIO function. Drop the property. Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20240412075613.1200048-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 573fb73db52f269e6a95a798a5edf42c26a2acc9 Author: AngeloGioacchino Del Regno Date: Tue Apr 9 13:42:08 2024 +0200 arm64: dts: medaitek: mt8395-nio-12l: Set i2c6 pins to bias-disable [ Upstream commit 32b33be8894f3389d15b409140d663acbdf9de1d ] GPIOs 25 and 26 do not support pull-up/pull-down when those are muxed as I2C6's SDA6/SCL6 lines: set those to bias-disable to avoid warning messages from the pinctrl driver. Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board") Link: https://lore.kernel.org/r/20240409114211.310462-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit e8f068a23a18bb0bceca2ea75d51960f208ecc1f Author: AngeloGioacchino Del Regno Date: Wed Apr 10 10:30:01 2024 +0200 arm64: dts: mediatek: mt8192: Fix GPU thermal zone name for SVS [ Upstream commit 86beeec5dd2b8e28217f67815a3fb15752031667 ] This SoC has two GPU related thermal zones: the primary zone must be called "gpu-thermal" for SVS to pick it up. Fixes: c7a728051f4e ("arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones") Link: https://lore.kernel.org/r/20240410083002.1357857-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 509a9dc5cf6650cdee602199bca58e4570707238 Author: AngeloGioacchino Del Regno Date: Wed Apr 10 10:30:00 2024 +0200 arm64: dts: mediatek: mt8195: Fix GPU thermal zone name for SVS [ Upstream commit b2b6f2edb82a08abe8942535bc77da55a0f43e14 ] This SoC has two GPU related thermal zones: the primary zone must be called "gpu-thermal" for SVS to pick it up. Fixes: 1e5b6725199f ("arm64: dts: mediatek: mt8195: Add AP domain thermal zones") Link: https://lore.kernel.org/r/20240410083002.1357857-2-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 70aa2d9b89d318b125561e8111c870acb1517e52 Author: Michael Walle Date: Mon Jun 17 11:13:38 2024 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix PCIe reset polarity [ Upstream commit df35c6e9027cf9affe699e632a48082ab1bbba4c ] The PCIe reset line is active low. Fix it. Fixes: 2a51f9dae13d ("ARM: dts: imx6qdl-kontron-samx6i: Add iMX6-based Kontron SMARC-sAMX6i module") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7f62fe7e0e85dd4ad68a81c0d690d62a5cdca63e Author: Michael Walle Date: Mon Jun 17 11:13:33 2024 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix SPI0 chip selects [ Upstream commit 74e1c956a68a65d642447d852e95b3fbb69bebaa ] There is a comment in the imx6q variant dtsi claiming that these modules will have one more chip select than the imx6dl variant. This is wrong. Ordinary GPIOs are used for chip selects and both variants of the module share the very same PCB and both have this GPIO routed to the SPI0_CS1# pin of the SMARC connector. Fix it by moving the third chip select description to the common dtsi. Fixes: 2125212785c9 ("ARM: dts: imx6qdl-kontron-samx6i: add Kontron SMARC SoM Support") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit b2490fc162b457e51e354fdffc63b20b9c64b0d1 Author: Michael Walle Date: Mon Jun 17 11:13:31 2024 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix board reset [ Upstream commit b972d6b3b46345023aee56a95df8e2c137aa4ee4 ] On i.MX6 the board is reset by the watchdog. But in turn to do a complete board reset, we have to assert the WDOG_B output which is routed also to the CPLD which then do a complete power-cycle of the board. Fixes: 2125212785c9 ("ARM: dts: imx6qdl-kontron-samx6i: add Kontron SMARC SoM Support") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 3326d475ddd7d38da03b10731e144112b5d3fc78 Author: Michael Walle Date: Mon Jun 17 11:13:30 2024 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix PHY reset [ Upstream commit edfea889a049abe80f0d55c0365bf60fbade272f ] The PHY reset line is connected to both the SoC (GPIO1_25) and the CPLD. We must not use the GPIO1_25 as it will drive against the output buffer of the CPLD. Instead there is another GPIO (GPIO2_01), an input to the CPLD, which will tell the CPLD to assert the PHY reset line. Fixes: 2a51f9dae13d ("ARM: dts: imx6qdl-kontron-samx6i: Add iMX6-based Kontron SMARC-sAMX6i module") Fixes: 5694eed98cca ("ARM: dts: imx6qdl-kontron-samx6i: move phy reset into phy-node") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 873aaa24d0398be4470cacac9c43a6f7bdd29fc8 Author: Michael Walle Date: Mon Jun 17 11:13:29 2024 +0200 ARM: dts: imx6qdl-kontron-samx6i: fix phy-mode [ Upstream commit 0df3c7d7a73d75153090637392c0b73a63cdc24a ] The i.MX6 cannot add any RGMII delays. The PHY has to add both the RX and TX delays on the RGMII interface. Fix the interface mode. While at it, use the new phy-connection-type property name. Fixes: 5694eed98cca ("ARM: dts: imx6qdl-kontron-samx6i: move phy reset into phy-node") Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 4025ecca3c790849624e6321c5f382464906619a Author: Jerome Brunet Date: Tue Jun 25 13:18:43 2024 +0200 arm64: dts: amlogic: sm1: fix spdif compatibles [ Upstream commit b0aba467c329a89e8b325eda0cf60776958353fe ] The spdif input and output of g12 and sm1 are compatible but sm1 should use the related compatible since it exists. Fixes: 86f2159468d5 ("arm64: dts: meson-sm1: add spdifin and pdifout nodes") Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20240625111845.928192-1-jbrunet@baylibre.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 9a9f8515c449d22034b88b4044fdb29ea6d59a1a Author: Jonas Karlman Date: Sat Jun 15 17:03:52 2024 +0000 arm64: dts: rockchip: Increase VOP clk rate on RK3328 [ Upstream commit 0f2ddb128fa20f8441d903285632f2c69e90fae1 ] The VOP on RK3328 needs to run at a higher rate in order to produce a proper 3840x2160 signal. Change to use 300MHz for VIO clk and 400MHz for VOP clk, same rates used by vendor 4.4 kernel. Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20240615170417.3134517-2-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit ba9fa7529a1493ad0be1010503fd3a01b144dba7 Author: Dmitry Baryshkov Date: Sat Jun 22 01:03:41 2024 +0300 soc: qcom: pdr: fix parsing of domains lists [ Upstream commit 57f20d51f35780f240ecf39d81cda23612800a92 ] While parsing the domains list, start offsets from 0 rather than from domains_read. The domains_read is equal to the total count of the domains we have seen, while the domains list in the message starts from offset 0. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Tested-by: Steev Klimaszewski Tested-by: Alexey Minnekhanov Reviewed-by: Chris Lew Tested-by: Neil Armstrong # on SM8550-QRD Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240622-qcom-pd-mapper-v9-2-a84ee3591c8e@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8543269567e2fb3d976a8255c5e348aed14f98bc Author: Dmitry Baryshkov Date: Sat Jun 22 01:03:40 2024 +0300 soc: qcom: pdr: protect locator_addr with the main mutex [ Upstream commit 107924c14e3ddd85119ca43c26a4ee1056fa9b84 ] If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Tested-by: Neil Armstrong # on SM8550-QRD Tested-by: Steev Klimaszewski Tested-by: Alexey Minnekhanov Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240622-qcom-pd-mapper-v9-1-a84ee3591c8e@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4100d4d019f8e140be1d4d3a9d8d93c1285f5d1c Author: Sibi Sankar Date: Thu Jun 13 22:15:06 2024 +0530 soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove [ Upstream commit 24086640ab39396eb1a92d1cb1cd2f31b2677c52 ] The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use. Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]--- Fixes: 0276f69f13e2 ("soc: qcom: icc-bwmon: Set default thresholds dynamically") Fixes: b9c2ae6cac40 ("soc: qcom: icc-bwmon: Add bandwidth monitoring driver") Signed-off-by: Sibi Sankar Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240613164506.982068-1-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9eacfd2ab4c61a23955fdd70209e0883e215de04 Author: Komal Bajaj Date: Tue Jun 18 14:57:11 2024 +0530 arm64: dts: qcom: qdu1000: Add secure qfprom node [ Upstream commit 367fb3f0aaa6eac9101dc683dd27c268b4cc702e ] Add secure qfprom node and also add properties for multi channel DDR. This is required for LLCC driver to pick the correct LLCC configuration. Fixes: 6209038f131f ("arm64: dts: qcom: qdu1000: Add LLCC/system-cache-controller") Signed-off-by: Komal Bajaj Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20240618092711.15037-1-quic_kbajaj@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a0f985672d68a822e3adfd45bf6157bd117f82bd Author: Nícolas F. R. A. Prado Date: Fri Jun 14 16:59:36 2024 -0400 arm64: dts: qcom: sc7180-trogdor: Disable pwmleds node where unused [ Upstream commit 99e94768c890c7522af020ff0e5e5317b2d046d9 ] Currently the keyboard backlight is described in the common sc7180-trogdor dtsi as an led node below a pwmleds node, and the led node is set to disabled. Only the boards that have a keyboard backlight enable it. However, since the parent pwmleds node is still enabled everywhere, even on boards that don't have keyboard backlight it is probed and fails, resulting in an error: leds_pwm pwmleds: probe with driver leds_pwm failed with error -22 as well as a failure in the DT kselftest: not ok 45 /pwmleds Fix this by controlling the status of the parent pwmleds node instead of the child led, based on the presence of keyboard backlight. This is what is done on sc7280 already. While at it add a missing blank line before the child node to follow the coding style. Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Konrad Dybcio Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20240614-sc7180-pwmleds-probe-v1-1-e2c3f1b42a43@collabora.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d998dcfff80a2bfe6e285a990a5f5e3b6b5565c Author: Jai Luthra Date: Thu Jun 6 13:37:46 2024 +0530 arm64: dts: ti: k3-am62p5-sk: Fix pinmux for McASP1 TX [ Upstream commit e96e36ce1fdcf08a70e3f09cbe2da02b073c58ac ] On SK-AM62P, McASP1 uses two pins for communicating with the codec over I2S protocol. One of these pins (AXR0) is used for audio playback (TX) so the direction of the pin should be OUTPUT. Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-7-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 3b2ce19ac2f7e48aad49f9a16f0619503f835d5a Author: Jai Luthra Date: Thu Jun 6 13:37:45 2024 +0530 arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Drop McASP AFIFOs [ Upstream commit 554dd562a5f2f5d7e838f7b229a1c612275678db ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: 28c0cf16b308 ("arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add Audio Codec") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-6-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 1322529b0c7820db94c058e970cd3274329c3cb7 Author: Jai Luthra Date: Thu Jun 6 13:37:44 2024 +0530 arm64: dts: ti: k3-am62-verdin: Drop McASP AFIFOs [ Upstream commit fb01352801f08740e9f37cbd71f73866c7044927 ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Acked-by: Francesco Dolcini Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-5-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit a4a03e2f485bf9993e74d8e4559eecfb33bdca34 Author: Jai Luthra Date: Thu Jun 6 13:37:43 2024 +0530 arm64: dts: ti: k3-am625-beagleplay: Drop McASP AFIFOs [ Upstream commit 3b4a03357aee07a32a44a49bb6a71f5e82b1ecc1 ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: 1f7226a5e52c ("arm64: dts: ti: k3-am625-beagleplay: Add HDMI support") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-4-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 4efa40f9dfe5838b59e554ecb6edb40d35828cae Author: Jai Luthra Date: Thu Jun 6 13:37:42 2024 +0530 arm64: dts: ti: k3-am62p5: Drop McASP AFIFOs [ Upstream commit d3fe4b4e2e44de64ed1f1585151bf4a3627adbaf ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-3-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit a8c6c5e13aba9e10b1a6f9de53d921a3857f5bcd Author: Jai Luthra Date: Thu Jun 6 13:37:41 2024 +0530 arm64: dts: ti: k3-am62a7: Drop McASP AFIFOs [ Upstream commit a931b81072921a11d5bb8e8201b6228b791d40a9 ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: 4a2c5dddf9e9 ("arm64: dts: ti: k3-am62a7-sk: Enable audio on AM62A") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-2-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 2a3e7f475866cf934df118227dbe8dbc4494f745 Author: Jai Luthra Date: Thu Jun 6 13:37:40 2024 +0530 arm64: dts: ti: k3-am62x: Drop McASP AFIFOs [ Upstream commit 6ee3ca0ec7fabc63603afdb3485da04164dc8747 ] McASP AFIFOs are not necessary with UDMA-P/BCDMA as there is buffering on the DMA IP. Drop these for better audio latency. Fixes: b94b43715e91 ("arm64: dts: ti: Enable audio on SK-AM62(-LP)") Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240606-mcasp_fifo_drop-v2-1-8c317dabdd0a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 9e6590af6999e3a3428450c724c27bc856a3f870 Author: Vaishnav Achath Date: Tue May 7 16:03:32 2024 +0530 arm64: dts: ti: k3-j722s: Fix main domain GPIO count [ Upstream commit 2cdf63e73415ce6c8f6b3397cdc91d5f928855f9 ] J722S does not pin out all of the GPIO same as AM62P and have more number of GPIO on the main_gpio1 instance. Fix the GPIO count on both instances by overriding the ti,ngpio property. Fixes: ea55b9335ad8 ("arm64: dts: ti: Introduce J722S family of SoCs") More details at J722S/AM67 Datasheet (Section 5.3.11, GPIO): https://www.ti.com/lit/ds/symlink/am67.pdf Signed-off-by: Vaishnav Achath Link: https://lore.kernel.org/r/20240507103332.167928-1-vaishnav.a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 2ea4abb96f2061617885ded61e16b17cd725feaa Author: Josua Mayer Date: Sat May 4 13:35:54 2024 +0200 arm64: dts: ti: k3-am642-hummingboard-t: correct rs485 rts polarity [ Upstream commit 9dcc0e1065f3c40d0b2ad79a858bb4ebaba33167 ] The RS485 transceiver RE (Receiver enable) and DE (Driver enable) are shorted and connected to both RTS/CTS of the SoC UART. RE is active-low, DE is active-high. Remove the "rs485-rts-active-low" flag to match RTS polarity with DE, and fix communication in both transmit and receive directions. Fixes: d60483faf914 ("arm64: dts: add description for solidrun am642 som and evaluation board") Signed-off-by: Josua Mayer Link: https://lore.kernel.org/r/20240504-ti-rs485-rts-v1-1-e88ef1c96f34@solid-run.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 98e86ab64873e69c835c0285ece0fa77f06fab9c Author: Jayesh Choudhary Date: Tue Apr 30 16:22:53 2024 +0530 arm64: dts: ti: k3-am62p-main: Fix the reg-range for main_pktdma [ Upstream commit a6e6604c600aeedf9700de4a55255850391bc3fc ] For main_pktdma node, the TX Channel Realtime Register region 'tchanrt' is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in memory map in the TRM[0] (Table 2-1). So fix ranges for those register regions. [0]: Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs") Signed-off-by: Jayesh Choudhary Reviewed-by: Udit Kumar Link: https://lore.kernel.org/r/20240430105253.203750-4-j-choudhary@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit 909ad4f81cc82c99e759ad2b3cf9ee0b8fd0be89 Author: Jayesh Choudhary Date: Tue Apr 30 16:22:52 2024 +0530 arm64: dts: ti: k3-am62a-main: Fix the reg-range for main_pktdma [ Upstream commit d007a883a61f55b9b195c4c18bbe29de5b802822 ] For main_pktdma node, the TX Channel Realtime Register region 'tchanrt' is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in memory map in the TRM[0] (Table 2-1). So fix ranges for those register regions. [0]: Fixes: 3dad70def7ff ("arm64: dts: ti: k3-am62a-main: Add more peripheral nodes") Signed-off-by: Jayesh Choudhary Reviewed-by: Udit Kumar Link: https://lore.kernel.org/r/20240430105253.203750-3-j-choudhary@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit f007e23ebd9a10a434684b08c6fe8a3b2154a9d7 Author: Jayesh Choudhary Date: Tue Apr 30 16:22:51 2024 +0530 arm64: dts: ti: k3-am62-main: Fix the reg-range for main_pktdma [ Upstream commit 6edad223553c7f1680fcaca25ded59eba7c6d82d ] For main_pktdma node, the TX Channel Realtime Register region 'tchanrt' is 128KB and Ring Realtime Register region 'ringrt' is 2MB as shown in memory map in the TRM[0] (Table 2-1). So fix ranges for those register regions. [0]: Fixes: c37c58fdeb8a ("arm64: dts: ti: k3-am62: Add more peripheral nodes") Signed-off-by: Jayesh Choudhary Reviewed-by: Udit Kumar Link: https://lore.kernel.org/r/20240430105253.203750-2-j-choudhary@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin commit ee56e86c3f211dfb0909daa7f54fb88ee68fdf77 Author: Esben Haabendal Date: Thu May 30 16:46:36 2024 +0200 memory: fsl_ifc: Make FSL_IFC config visible and selectable [ Upstream commit 9ba0cae3cac07c21c583f9ff194f74043f90d29c ] While use of fsl_ifc driver with NAND flash is fine, as the fsl_ifc_nand driver selects FSL_IFC automatically, we need the CONFIG_FSL_IFC option to be selectable for platforms using fsl_ifc with NOR flash. Fixes: ea0c0ad6b6eb ("memory: Enable compile testing for most of the drivers") Reviewed-by: Miquel Raynal Signed-off-by: Esben Haabendal Link: https://lore.kernel.org/r/20240530-fsl-ifc-config-v3-1-1fd2c3d233dd@geanix.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit f666c421e1d7890ae0d2efcb97423dee3b0f51b0 Author: Primoz Fiser Date: Thu Jun 6 09:01:27 2024 +0200 OPP: ti: Fix ti_opp_supply_probe wrong return values [ Upstream commit 3a1ac6b8f603a9310274990a0ad563a5fb709f59 ] Function ti_opp_supply_probe() since commit 6baee034cb55 ("OPP: ti: Migrate to dev_pm_opp_set_config_regulators()") returns wrong values when all goes well and hence driver probing eventually fails. Fixes: 6baee034cb55 ("OPP: ti: Migrate to dev_pm_opp_set_config_regulators()") Signed-off-by: Primoz Fiser Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit c9fdb8980b781725dccc1f40689f508b768e7ea9 Author: Konrad Dybcio Date: Fri May 10 14:58:31 2024 +0200 arm64: dts: qcom: sc8280xp: Throttle the GPU when overheating [ Upstream commit f7fd6d04c1046107a87a0fc883ed044cf8b877a1 ] Add an 85C passive trip point with 1C of hysteresis to ensure the thermal framework takes sufficient action to prevent reaching junction temperature. Also, add passive polling to ensure more than one temperature change event is recorded. Fixes: 014bbc990e27 ("arm64: dts: qcom: sc8280xp: Introduce additional tsens instances") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-2-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a291feafde81e57226af26d5d43521eb9643c0ed Author: Konrad Dybcio Date: Fri May 10 13:59:42 2024 +0200 arm64: dts: qcom: sc8280xp-*: Remove thermal zone polling delays [ Upstream commit e388421387e8b1b51c507883aaf13f40277fe137 ] All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-19-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: f7fd6d04c104 ("arm64: dts: qcom: sc8280xp: Throttle the GPU when overheating") Signed-off-by: Sasha Levin commit 233c60cdcf99e15c3f37fecce1368bdeec48fd5d Author: Primoz Fiser Date: Thu Jun 6 08:58:47 2024 +0200 cpufreq: ti-cpufreq: Handle deferred probe with dev_err_probe() [ Upstream commit 101388b8ef1027be72e399beeb97293cce67bb24 ] Handle deferred probing gracefully by using dev_err_probe() to not spam console with unnecessary error messages. Fixes: f88d152dc739 ("cpufreq: ti: Migrate to dev_pm_opp_set_config()") Signed-off-by: Primoz Fiser Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 057850ed81c4fe590070c4999f6c45056e7e8006 Author: Dmitry Baryshkov Date: Wed Jun 5 12:00:49 2024 +0300 arm64: dts: qcom: qrb4210-rb2: make L9A always-on [ Upstream commit d6c6b85bf5582bbe2efefa9a083178b5f7eef439 ] The L9A regulator is used to further control voltage regulators on the board. It can be used to disable VBAT_mains, 1.8V, 3.3V, 5V rails). Make sure that is stays always on to prevent undervolting of these volage rails. Fixes: 8d58a8c0d930 ("arm64: dts: qcom: Add base qrb4210-rb2 board dts") Reviewed-by: Bryan O'Donoghue Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240605-rb2-l9a-aon-v2-1-0d493d0d107c@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0c269c1f58d743188d6c115f8f793b9ab37a8948 Author: Marek Vasut Date: Mon May 13 23:58:15 2024 +0200 ARM: dts: stm32: Add arm,no-tick-in-suspend to STM32MP15xx STGEN timer [ Upstream commit 4306c047415a227bc72f0e7ba9bde1ccdac10435 ] STM32MP15xx RM0436 Rev 6 section 46.3 System timer generator (STGEN) states " Arm recommends that the system counter is in an always-on power domain. This is not supported in the current implementation, therefore STGEN should be saved and restored before Standby mode entry, and restored at Standby exit by secure software. ... " Instead of piling up workarounds in the firmware which is difficult to update, add "arm,no-tick-in-suspend" DT property into the timer node to indicate the timer is stopped in suspend, and let the kernel fix the timer up. Fixes: 8471a20253eb ("ARM: dts: stm32: add stm32mp157c initial support") Signed-off-by: Marek Vasut Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 8938217a8d672d5500d975691f6c1472c383a6ec Author: Pavel Löbl Date: Wed Mar 20 07:10:19 2024 +0100 ARM: dts: sunxi: remove duplicated entries in makefile [ Upstream commit bba474656dd85b13e4c5d5bdb73ca08d9136df21 ] During introduction of DTS vendor subdirectories in 724ba6751532, sun8i section of the makefile got duplicated. Clean that up. Fixes: 724ba6751532 ("ARM: dts: Move .dts files to vendor sub-directories") Signed-off-by: Pavel Löbl Reviewed-by: Jernej Skrabec Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/20240320061027.4078852-1-pavel@loebl.cz Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit f762acdaff9e54688be16e6c832c73a61533c1df Author: Jay Buddhabhatti Date: Mon Apr 8 04:06:10 2024 -0700 soc: xilinx: rename cpu_number1 to dummy_cpu_number [ Upstream commit 4a95449dd975e2ea6629a034f3e74b46c9634916 ] The per cpu variable cpu_number1 is passed to xlnx_event_handler as argument "dev_id", but it is not used in this function. So drop the initialization of this variable and rename it to dummy_cpu_number. This patch is to fix the following call trace when the kernel option CONFIG_DEBUG_ATOMIC_SLEEP is enabled: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT) Call trace: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74/0x138 xlnx_event_manager_probe+0xf8/0x298 platform_probe+0x68/0xd8 Fixes: daed80ed0758 ("soc: xilinx: Fix for call trace due to the usage of smp_processor_id()") Signed-off-by: Jay Buddhabhatti Link: https://lore.kernel.org/r/20240408110610.15676-1-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 312396939bf5bf045315a65ca24a2cb86cb6b338 Author: Sagar Cheluvegowda Date: Tue May 14 17:06:51 2024 -0700 arm64: dts: qcom: sa8775p: mark ethernet devices as DMA-coherent [ Upstream commit 49cc31f8ab44e60d8109da7e18c0983a917d4d74 ] Ethernet devices are cache coherent, mark it as such in the dtsi. Fixes: ff499a0fbb23 ("arm64: dts: qcom: sa8775p: add the first 1Gb ethernet interface") Fixes: e952348a7cc7 ("arm64: dts: qcom: sa8775p: add a node for EMAC1") Signed-off-by: Sagar Cheluvegowda Link: https://lore.kernel.org/r/20240514-mark_ethernet_devices_dma_coherent-v4-1-04e1198858c5@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 611d4a831342353a19cf38aed54a22a1ac8d918d Author: Dmitry Baryshkov Date: Mon Apr 8 03:04:31 2024 +0300 arm64: dts: qcom: msm8996: specify UFS core_clk frequencies [ Upstream commit 02f838b7f8cdfb7a96b7f08e7f6716f230bdecba ] Follow the example of other platforms and specify core_clk frequencies in the frequency table in addition to the core_clk_src frequencies. The driver should be setting the leaf frequency instead of some interim clock freq. Suggested-by: Nitin Rawat Fixes: 57fc67ef0d35 ("arm64: dts: qcom: msm8996: Add ufs related nodes") Reviewed-by: Konrad Dybcio Reviewed-by: Manivannan Sadhasivam Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240408-msm8996-fix-ufs-v4-1-ee1a28bf8579@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 504652b2eed845d02ed576c28d75caee584bd97d Author: Viresh Kumar Date: Tue May 28 10:58:37 2024 +0530 OPP: Fix missing cleanup on error in _opp_attach_genpd() [ Upstream commit d86a2f0800683652004490c590b4b96a63e7fc04 ] A recent commit updated the code mistakenly to return directly on errors, without doing the required cleanups. Fix it. Fixes: 2a56c462fe5a ("OPP: Fix required_opp_tables for multiple genpds using same table") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202405180016.4fbn86bm-lkp@intel.com/ Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 232c1085fcd9f15c80cdc1b4826e14623c2eeb43 Author: Javier Carrasco Date: Fri May 3 19:52:32 2024 +0200 cpufreq: sun50i: fix memory leak in dt_has_supported_hw() [ Upstream commit 6282fba6abd7c3c8896c239cc8aa9ec45edcb97b ] The for_each_child_of_node() loop does not decrement the child node refcount before the break instruction, even though the node is no longer required. This can be avoided with the new for_each_child_of_node_scoped() macro that removes the need for any of_node_put(). Fixes: fa5aec9561cf ("cpufreq: sun50i: Add support for opp_supported_hw") Signed-off-by: Javier Carrasco Reviewed-by: Andre Przywara Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 1390b9f652283dd4a8a28d6a126dc0678d6caf5c Author: Jonas Karlman Date: Tue May 21 21:10:16 2024 +0000 arm64: dts: rockchip: Update WIFi/BT related nodes on rk3308-rock-pi-s [ Upstream commit 12c3ec878cbe3709782e85b88124abecc3bb8617 ] Update WiFi SDIO and BT UART related props to better reflect details about the optional onboard RTL8723DS WiFi/BT module. Also correct the compatible used for bluetooth to match the WiFi/BT module used on the board. Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20240521211029.1236094-14-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 68dea92d678af7352cc895ff5cbbfe41a6e1fb35 Author: Jonas Karlman Date: Tue May 21 21:10:10 2024 +0000 arm64: dts: rockchip: Add mdio and ethernet-phy nodes to rk3308-rock-pi-s [ Upstream commit 4b64ed510ed946a4e4ca6d51d6512bf5361f6a04 ] Be explicit about the Ethernet port and define mdio and ethernet-phy nodes in the device tree for ROCK Pi S. Fixes: bc3753aed81f ("arm64: dts: rockchip: rock-pi-s add more peripherals") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20240521211029.1236094-8-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit bcbed5fee3e5f06be1dc8a73f4933bcae688089e Author: Jonas Karlman Date: Tue May 21 21:10:08 2024 +0000 arm64: dts: rockchip: Add pinctrl for UART0 to rk3308-rock-pi-s [ Upstream commit 7affb86ef62581e3475ce3e0a7640da1f2ee29f8 ] UAR0 CTS/RTS is not wired to any pin and is not used for the default serial console use of UART0 on ROCK Pi S. Override the SoC defined pinctrl props to limit configuration of the two xfer pins wired to one of the GPIO pin headers. Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20240521211029.1236094-6-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 90e63ee2879ef1883953cc9be477afc3d6218955 Author: Jonas Karlman Date: Tue May 21 21:10:07 2024 +0000 arm64: dts: rockchip: Add sdmmc related properties on rk3308-rock-pi-s [ Upstream commit fc0daeccc384233eadfa9d5ddbd00159653c6bdc ] Add cap-mmc-highspeed to allow use of high speed MMC mode using an eMMC to uSD board. Use disable-wp to signal that no physical write-protect line is present. Also add vcc_io used for card and IO line power as vmmc-supply. Fixes: 2e04c25b1320 ("arm64: dts: rockchip: add ROCK Pi S DTS support") Signed-off-by: Jonas Karlman Link: https://lore.kernel.org/r/20240521211029.1236094-5-jonas@kwiboo.se Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f7b9e814ab8d4b538f8998f04bd712d29522d827 Author: Stephen Boyd Date: Thu May 9 11:41:28 2024 -0700 soc: qcom: rpmh-rsc: Ensure irqs aren't disabled by rpmh_rsc_send_data() callers [ Upstream commit e43111f52b9ec5c2d700f89a1d61c8d10dc2d9e9 ] Dan pointed out that Smatch is concerned about this code because it uses spin_lock_irqsave() and then calls wait_event_lock_irq() which enables irqs before going to sleep. The comment above the function says it should be called with interrupts enabled, but we simply hope that's true without really confirming that. Let's add a might_sleep() here to confirm that interrupts and preemption aren't disabled. Once we do that, we can change the lock to be non-saving, spin_lock_irq(), to clarify that we don't expect irqs to be disabled. If irqs are disabled by callers they're going to be enabled anyway in the wait_event_lock_irq() call which would be bad. This should make Smatch happier and find bad callers faster with the might_sleep(). We can drop the WARN_ON() in the caller because we have the might_sleep() now, simplifying the code. Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/911181ed-c430-4592-ad26-4dc948834e08@moroto.mountain Fixes: 2bc20f3c8487 ("soc: qcom: rpmh-rsc: Sleep waiting for tcs slots to be free") Cc: Douglas Anderson Signed-off-by: Stephen Boyd Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20240509184129.3924422-1-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2dcefd6d1e71111ccfb7362dc7fcf4dc71959fa7 Author: Chen Ni Date: Fri May 10 16:31:56 2024 +0800 soc: qcom: pmic_glink: Handle the return value of pmic_glink_init [ Upstream commit 0780c836673b25f5aad306630afcb1172d694cb4 ] As platform_driver_register() and register_rpmsg_driver() can return error numbers, it should be better to check the return value and deal with the exception. Signed-off-by: Chen Ni Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20240510083156.1996783-1-nichen@iscas.ac.cn Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 501db89e28fea2b8192a2496ce0848bb052ed998 Author: Marc Gonzalez Date: Wed May 15 16:27:44 2024 +0200 arm64: dts: qcom: msm8998: enable adreno_smmu by default [ Upstream commit 98a0c4f2278b4d6c1c7722735c20b2247de6293f ] 15 qcom platform DTSI files define an adreno_smmu node. msm8998 is the only one with adreno_smmu disabled by default. There's no reason why this SMMU should be disabled by default, it doesn't need any further configuration. Bring msm8998 in line with the 14 other platforms. This fixes GPU init failing with ENODEV: msm_dpu c901000.display-controller: failed to load adreno gpu msm_dpu c901000.display-controller: failed to bind 5000000.gpu (ops a3xx_ops): -19 Fixes: 87cd46d68aeac8 ("Configure Adreno GPU and related IOMMU") Signed-off-by: Marc Gonzalez Reviewed-by: Bryan O'Donoghue Reviewed-by: Marijn Suijten Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/be51d1a4-e8fc-48d1-9afb-a42b1d6ca478@freebox.fr Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit fbf852d429e4454247106d4b638a14d4b940e60d Author: Dmitry Baryshkov Date: Mon May 27 07:00:22 2024 +0300 arm64: dts: qcom: sdm850-lenovo-yoga-c630: fix IPA firmware path [ Upstream commit cae4c862d8b2d7debb07e6d831e079520163ac4f ] Specify firmware path for the IPA network controller on the Lenovo Yoga C630 laptop. Without this property IPA tries to load firmware from the default location, which likely will fail. Fixes: 2e01e0c21459 ("arm64: dts: qcom: sdm850-yoga: Enable IPA") Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240527-yoga-ipa-fw-v1-1-99ac1f5db283@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 94afdaa14344d8697c41edf56b0da12d848c6750 Author: Dmitry Baryshkov Date: Wed May 1 19:19:39 2024 +0300 arm64: dts: qcom: msm8996-xiaomi-common: drop excton from the USB PHY [ Upstream commit c1aefeae8cb7b71c1bb6d33b1bda7fc322094e16 ] The USB PHYs don't use extcon connectors, drop the extcon property from the hsusb_phy1 node. Fixes: 46680fe9ba61 ("arm64: dts: qcom: msm8996: Add support for the Xiaomi MSM8996 platform") Cc: Yassine Oudjana Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-13-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e93112293d20a82bdeaf3571dc9ad836ef9e60d0 Author: Dmitry Baryshkov Date: Wed May 1 19:19:37 2024 +0300 arm64: dts: qcom: sm8450: add power-domain to UFS PHY [ Upstream commit 27d3f57cf5a71484ea38770d4bfd10f6ef035cf4 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: 07fa917a335e ("arm64: dts: qcom: sm8450: add ufs nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-11-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8533f637f662056eecb92f6bd5c05c8a4994d111 Author: Dmitry Baryshkov Date: Wed May 1 19:19:36 2024 +0300 arm64: dts: qcom: sm8350: add power-domain to UFS PHY [ Upstream commit 634acc8cea1584b507801315831a330443f819b4 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: 59c7cf814783 ("arm64: dts: qcom: sm8350: Add UFS nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-10-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b042cf07c9aaf8697c43c1aa4b3e2b665123922c Author: Dmitry Baryshkov Date: Wed May 1 19:19:35 2024 +0300 arm64: dts: qcom: sm8250: add power-domain to UFS PHY [ Upstream commit 154ed5ea328d8a97a4ef5d1447e6f06d11fe2bbe ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: b7e2fba06622 ("arm64: dts: qcom: sm8250: Add UFS controller and PHY") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-9-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8c93c87cfa8991bf97dd220a3277d606d3f6b953 Author: Dmitry Baryshkov Date: Wed May 1 19:19:34 2024 +0300 arm64: dts: qcom: sm6350: add power-domain to UFS PHY [ Upstream commit 18c2727282c5264ff5502daac26c43000e8eb202 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: 5a814af5fc22 ("arm64: dts: qcom: sm6350: Add UFS nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-8-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b5357d8fc93f65f71cf9bb8382fc4ed2d3ed5707 Author: Dmitry Baryshkov Date: Wed May 1 19:19:33 2024 +0300 arm64: dts: qcom: sm6115: add power-domain to UFS PHY [ Upstream commit a9eb454873a813ddc4578e5c3b37778de6fda472 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: 97e563bf5ba1 ("arm64: dts: qcom: sm6115: Add basic soc dtsi") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-7-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 080bcc8cce96a218b2242aff058a8c48f206f728 Author: Dmitry Baryshkov Date: Wed May 1 19:19:32 2024 +0300 arm64: dts: qcom: sdm845: add power-domain to UFS PHY [ Upstream commit fd39ae8b9bc10419b1e4b849cdbc6755a967ade1 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: cc16687fbd74 ("arm64: dts: qcom: sdm845: add UFS controller") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-6-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bec81d919cfac636aad662b70a7e1cbd27520ad7 Author: Dmitry Baryshkov Date: Wed May 1 19:19:31 2024 +0300 arm64: dts: qcom: sc8180x: add power-domain to UFS PHY [ Upstream commit 9a80ecce60bd4919019a3cdb64604c9b183a8518 ] The UFS PHY is powered on via the UFS_PHY_GDSC power domain. Add corresponding power-domain the the PHY node. Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-5-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 138abbabf63b9b831cc65c8ad94bb4f9332d209c Author: Dmitry Baryshkov Date: Wed May 1 19:19:30 2024 +0300 arm64: dts: qcom: sc7180: drop extra UFS PHY compat [ Upstream commit 48299f604d27dad1168cc90b89f33853162c6e33 ] The DT schema doesn't have a fallback compatible for qcom,sc7180-qmp-ufs-phy. Drop it from the dtsi too. Fixes: 858536d9dc94 ("arm64: dts: qcom: sc7180: Add UFS nodes") Signed-off-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-4-f1fd15c33fb3@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a8d494762c4ff85b4e63ee669462b9eb5abf4bce Author: Rayyan Ansari Date: Wed Apr 24 18:42:06 2024 +0100 ARM: dts: qcom: msm8226-microsoft-common: Enable smbb explicitly [ Upstream commit 81a0a21b6159c6a9ed1e39c23e755cd05a102ce3 ] Enable the smbb node explicitly for MSM8x26 Lumia devices. These devices rely on the smbb driver in order to detect USB state. It seems that this was accidentally missed in the commit that this fixes. Fixes: c9c8179d0ccd ("ARM: dts: qcom: Disable pm8941 & pm8226 smbb charger by default") Signed-off-by: Rayyan Ansari Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240424174206.4220-1-rayyan@ansari.sh Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 85610b00af7525c40fba4c21cd2f82507776c9c2 Author: Viken Dadhaniya Date: Wed Apr 24 13:28:53 2024 +0530 arm64: dts: qcom: sc7280: Remove CTS/RTS configuration [ Upstream commit 2b96407b8f10f1d71b58cb35704eb91b8ea78db1 ] For IDP variant, GPIO 20/21 is used by camera use case and camera driver is not able acquire these GPIOs as it is acquired by UART5 driver as RTS/CTS pin. UART5 is designed for debug UART for all the board variants of the sc7280 chipset and RTS/CTS configuration is not required for debug uart usecase. Remove CTS/RTS configuration for UART5 instance and change compatible string to debug UART. Remove overwriting compatible property from individual target specific file as it is not required. Fixes: 38cd93f413fd ("arm64: dts: qcom: sc7280: Update QUPv3 UART5 DT node") Signed-off-by: Viken Dadhaniya Link: https://lore.kernel.org/r/20240424075853.11445-1-quic_vdadhani@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6dbc8239be9c00a935cccd4452c907fda768fec6 Author: Bjorn Andersson Date: Sat May 25 10:56:20 2024 -0700 arm64: dts: qcom: sc8180x: Correct PCIe slave ports [ Upstream commit dc402e084a9e0cc714ffd6008dce3c63281b8142 ] The interconnects property was clearly copy-pasted between the 4 PCIe controllers, giving all four the cpu-pcie path destination of SLAVE_0. The four ports are all associated with CN0, but update the property for correctness sake. Fixes: d20b6c84f56a ("arm64: dts: qcom: sc8180x: Add PCIe instances") Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240525-sc8180x-pcie-interconnect-port-fix-v1-1-f86affa02392@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c1ae2a706e77637abd42c41cacc5307411f7c58b Author: Konrad Dybcio Date: Wed May 22 13:33:43 2024 +0200 soc: qcom: socinfo: Update X1E PMICs [ Upstream commit 85f5656a4f3f188cb950cf8dc88f3f0e4e656bae ] Assign the correct name to ID 82 and fix the ID of SMB2360. Fixes: e025171d1ab1 ("soc: qcom: socinfo: Add SMB2360 PMIC") Signed-off-by: Konrad Dybcio Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240522-topic-x1e_pmics_socinfo-v1-1-da8a097e5134@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bc29bc14c21699dfa8d56ef6155a5dd43c2ecb26 Author: Guenter Roeck Date: Sat Jul 13 12:03:53 2024 -0700 hwmon: (max6697) Fix swapped temp{1,8} critical alarms [ Upstream commit 1ea3fd1eb9869fcdcbc9c68f9728bfc47b9503f1 ] The critical alarm bit for the local temperature sensor (temp1) is in bit 7 of register 0x45 (not bit 6), and the critical alarm bit for remote temperature sensor 7 (temp8) is in bit 6 (not bit 7). This only affects MAX6581 since all other chips supported by this driver do not support those critical alarms. Fixes: 5372d2d71c46 ("hwmon: Driver for Maxim MAX6697 and compatibles") Reviewed-by: Tzung-Bi Shih Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7c7cf939b3b210ae92e80b078a29d63c20782743 Author: Guenter Roeck Date: Sat Jul 13 14:26:19 2024 -0700 hwmon: (max6697) Fix underflow when writing limit attributes [ Upstream commit cbf7467828cd4ec7ceac7a8b5b5ddb2f69f07b0e ] Using DIV_ROUND_CLOSEST() on an unbound value can result in underflows. Indeed, module test scripts report: temp1_max: Suspected underflow: [min=0, read 255000, written -9223372036854775808] temp1_crit: Suspected underflow: [min=0, read 255000, written -9223372036854775808] Fix by introducing an extra set of clamping. Fixes: 5372d2d71c46 ("hwmon: Driver for Maxim MAX6697 and compatibles") Reviewed-by: Tzung-Bi Shih Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 9fab017e2ea4b2a8118450d559333a2eeab815c5 Author: Nirmoy Das Date: Mon Jul 8 14:59:18 2024 +0200 drm/xe/display/xe_hdcp_gsc: Free arbiter on driver removal [ Upstream commit 609458abd5a10180f513ca364d6c0ae30128c821 ] Free arbiter allocated in intel_hdcp_gsc_init(). Fixes: 152f2df954d8 ("drm/xe/hdcp: Enable HDCP for XE") Cc: Suraj Kandpal Cc: Arun R Murthy Cc: Lucas De Marchi Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240708125918.23573-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das (cherry picked from commit 33891539f9d6f245e93a76e3fb5791338180374f) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin commit 1e6805b6ecf79114d03c8c9ba5b226489498b850 Author: Uwe Kleine-König Date: Tue Jul 9 12:18:05 2024 +0200 pwm: atmel-tcb: Fix race condition and convert to guards [ Upstream commit 37f7707077f5ea2515bf4b1dc7fad43f8e12993e ] The hardware only supports a single period length for both PWM outputs. So atmel_tcb_pwm_config() checks the configuration of the other output if it's compatible with the currently requested setting. The register values are then actually updated in atmel_tcb_pwm_enable(). To make this race free the lock must be held during the whole process, so grab the lock in .apply() instead of individually in atmel_tcb_pwm_disable() and atmel_tcb_pwm_enable() which then also covers atmel_tcb_pwm_config(). To simplify handling, use the guard helper to let the compiler care for unlocking. Otherwise unlocking would be more difficult as there is more than one exit path in atmel_tcb_pwm_apply(). Fixes: 9421bade0765 ("pwm: atmel: add Timer Counter Block PWM driver") Signed-off-by: Uwe Kleine-König Acked-by: Nicolas Ferre Link: https://lore.kernel.org/r/20240709101806.52394-3-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 8afada330c16c8304a6037867b65927e663c137f Author: Yao Zi Date: Wed Jul 3 15:58:27 2024 +0000 drm/meson: fix canvas release in bind function [ Upstream commit a695949b2e9bb6b6700a764c704731a306c4bebf ] Allocated canvases may not be released on the error exit path of meson_drv_bind_master(), leading to resource leaking. Rewrite exit path to release canvases on error. Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider module") Signed-off-by: Yao Zi Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240703155826.10385-2-ziyao@disroot.org Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240703155826.10385-2-ziyao@disroot.org Signed-off-by: Sasha Levin commit a0d154583030585dd71d83ceff5ba9260f6ccab2 Author: Gaosheng Cui Date: Sat Jul 6 14:46:25 2024 +0800 nvmet-auth: fix nvmet_auth hash error handling [ Upstream commit 89f58f96d1e2357601c092d85b40a2109cf25ef3 ] If we fail to call nvme_auth_augmented_challenge, or fail to kmalloc for shash, we should free the memory allocation for challenge, so add err path out_free_challenge to fix the memory leak. Fixes: 7a277c37d352 ("nvmet-auth: Diffie-Hellman key exchange support") Signed-off-by: Gaosheng Cui Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 069f34f991cd6c858deecf4c3dbcee5096c09f5a Author: Jinjie Ruan Date: Thu Jun 20 14:36:00 2024 +0800 arm64: smp: Fix missing IPI statistics [ Upstream commit 916b93f4e865b35563902f5862b443fc122631b4 ] commit 83cfac95c018 ("genirq: Allow interrupts to be excluded from /proc/interrupts") is to avoid IPIs appear twice in /proc/interrupts. But the commit 331a1b3a836c ("arm64: smp: Add arch support for backtrace using pseudo-NMI") and commit 2f5cd0c7ffde("arm64: kgdb: Implement kgdb_roundup_cpus() to enable pseudo-NMI roundup") set CPU_BACKTRACE and KGDB_ROUNDUP IPIs "IRQ_HIDDEN" flag but not show them in arch_show_interrupts(), which cause the interrupt kstat_irqs accounting is missing in display. Before this patch, CPU_BACKTRACE and KGDB_ROUNDUP IPIs are missing: / # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 11: 466 600 309 332 GICv3 27 Level arch_timer 13: 24 0 0 0 GICv3 33 Level uart-pl011 15: 64 0 0 0 GICv3 78 Edge virtio0 16: 0 0 0 0 GICv3 79 Edge virtio1 17: 0 0 0 0 GICv3 34 Level rtc-pl031 18: 3 3 3 3 GICv3 23 Level arm-pmu 19: 0 0 0 0 9030000.pl061 3 Edge GPIO Key Poweroff IPI0: 7 14 9 26 Rescheduling interrupts IPI1: 354 93 233 255 Function call interrupts IPI2: 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 0 0 0 0 Timer broadcast interrupts IPI5: 1 0 0 0 IRQ work interrupts Err: 0 After this pacth, CPU_BACKTRACE and KGDB_ROUNDUP IPIs are displayed: / # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 11: 393 281 532 449 GICv3 27 Level arch_timer 13: 15 0 0 0 GICv3 33 Level uart-pl011 15: 64 0 0 0 GICv3 78 Edge virtio0 16: 0 0 0 0 GICv3 79 Edge virtio1 17: 0 0 0 0 GICv3 34 Level rtc-pl031 18: 2 2 2 2 GICv3 23 Level arm-pmu 19: 0 0 0 0 9030000.pl061 3 Edge GPIO Key Poweroff IPI0: 11 19 4 23 Rescheduling interrupts IPI1: 279 347 222 72 Function call interrupts IPI2: 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts IPI4: 0 0 0 0 Timer broadcast interrupts IPI5: 1 0 0 1 IRQ work interrupts IPI6: 0 0 0 0 CPU backtrace interrupts IPI7: 0 0 0 0 KGDB roundup interrupts Err: 0 Fixes: 331a1b3a836c ("arm64: smp: Add arch support for backtrace using pseudo-NMI") Signed-off-by: Jinjie Ruan Suggested-by: Doug Anderson Acked-by: Will Deacon Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20240620063600.573559-1-ruanjinjie@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit ee6669355fa433cd0c4a6b5d8179fe5bffbdcaf0 Author: Adam Ford Date: Sun Jun 30 17:19:31 2024 -0500 drm/bridge: adv7511: Fix Intermittent EDID failures [ Upstream commit 91f9f4a37124044089debb02a3965c59b5b10c21 ] In the process of adding support for shared IRQ pins, a scenario was accidentally created where adv7511_irq_process returned prematurely causing the EDID to fail randomly. Since the interrupt handler is broken up into two main helper functions, update both of them to treat the helper functions as IRQ handlers. These IRQ routines process their respective tasks as before, but if they determine that actual work was done, mark the respective IRQ status accordingly, and delay the check until everything has been processed. This should guarantee the helper functions don't return prematurely while still returning proper values of either IRQ_HANDLED or IRQ_NONE. Reported-by: Liu Ying Fixes: f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins") Signed-off-by: Adam Ford Tested-by: Liu Ying # i.MX8MP EVK ADV7535 EDID retrieval w/o IRQ Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20240630221931.1650565-1-aford173@gmail.com Signed-off-by: Dmitry Baryshkov V3: Remove unnecessary declaration of ret by evaluating the return code of regmap_read directly. V2: Fix uninitialized cec_status Cut back a little on error handling to return either IRQ_NONE or IRQ_HANDLED. Signed-off-by: Sasha Levin commit b1c83176c1d77babeb142764c97582034cc6ba69 Author: Uwe Kleine-König Date: Wed Jul 3 13:00:06 2024 +0200 pwm: stm32: Always do lazy disabling [ Upstream commit 7346e7a058a2c9aa9ff1cc699c7bf18a402d9f84 ] When the state changes from enabled to disabled, polarity, duty_cycle and period are not configured in hardware and TIM_CCER_CCxE is just cleared. However if the state changes from one disabled state to another, all parameters are written to hardware because the early exit from stm32_pwm_apply() is only taken if the pwm is currently enabled. This yields surprises like: Applying { .period = 1, .duty_cycle = 0, .enabled = false } succeeds if the pwm is initially on, but fails if it's already off because 1 is a too small period. Update the check for lazy disable to always exit early if the target state is disabled, no matter what is currently configured. Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20240703110010.672654-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit c180311c0a520692e2d0e9ca44dcd6c2ff1b41c4 Author: Dan Carpenter Date: Thu Jul 4 10:18:59 2024 -0500 hwmon: (ltc2991) re-order conditions to fix off by one bug [ Upstream commit 99bf7c2eccff82760fa23ce967cc67c8c219c6a6 ] LTC2991_T_INT_CH_NR is 4. The st->temp_en[] array has LTC2991_MAX_CHANNEL (4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we have read one element beyond the end of the array. Flip the conditions around so that we check if "channel" is valid before using it as an array index. Fixes: 2b9ea4262ae9 ("hwmon: Add driver for ltc2991") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/Zoa9Y_UMY4_ROfhF@stanley.mountain Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 0c7429256de1d0b6c33126008b80551712a3b5b5 Author: Benjamin Marzinski Date: Tue Jul 2 11:18:02 2024 -0400 md/raid5: recheck if reshape has finished with device_lock held [ Upstream commit 25b3a8237a03ec0b67b965b52d74862e77ef7115 ] When handling an IO request, MD checks if a reshape is currently happening, and if so, where the IO sector is in relation to the reshape progress. MD uses conf->reshape_progress for both of these tasks. When the reshape finishes, conf->reshape_progress is set to MaxSector. If this occurs after MD checks if the reshape is currently happening but before it calls ahead_of_reshape(), then ahead_of_reshape() will end up comparing the IO sector against MaxSector. During a backwards reshape, this will make MD think the IO sector is in the area not yet reshaped, causing it to use the previous configuration, and map the IO to the sector where that data was before the reshape. This bug can be triggered by running the lvm2 lvconvert-raid-reshape-linear_to_raid6-single-type.sh test in a loop, although it's very hard to reproduce. Fix this by factoring the code that checks where the IO sector is in relation to the reshape out to a helper called get_reshape_loc(), which reads reshape_progress and reshape_safe while holding the device_lock, and then rechecks if the reshape has finished before calling ahead_of_reshape with the saved values. Also use the helper during the REQ_NOWAIT check to see if the location is inside of the reshape region. Fixes: fef9c61fdfabf ("md/raid5: change reshape-progress measurement to cope with reshaping backwards.") Signed-off-by: Benjamin Marzinski Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240702151802.1632010-1-bmarzins@redhat.com Signed-off-by: Sasha Levin commit dc72af89c94bdea5f37aad257776688ccc9f085f Author: Yu Kuai Date: Thu Jun 27 19:23:21 2024 +0800 md: Don't wait for MD_RECOVERY_NEEDED for HOT_REMOVE_DISK ioctl [ Upstream commit a1fd37f97808db4fa1bf55da0275790c42521e45 ] Commit 90f5f7ad4f38 ("md: Wait for md_check_recovery before attempting device removal.") explained in the commit message that failed device must be reomoved from the personality first by md_check_recovery(), before it can be removed from the array. That's the reason the commit add the code to wait for MD_RECOVERY_NEEDED. However, this is not the case now, because remove_and_add_spares() is called directly from hot_remove_disk() from ioctl path, hence failed device(marked faulty) can be removed from the personality by ioctl. On the other hand, the commit introduced a performance problem that if MD_RECOVERY_NEEDED is set and the array is not running, ioctl will wait for 5s before it can return failure to user. Since the waiting is not needed now, fix the problem by removing the waiting. Fixes: 90f5f7ad4f38 ("md: Wait for md_check_recovery before attempting device removal.") Reported-by: Mateusz Kusiak Closes: https://lore.kernel.org/all/814ff6ee-47a2-4ba0-963e-cf256ee4ecfa@linux.intel.com/ Signed-off-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240627112321.3044744-1-yukuai1@huaweicloud.com Signed-off-by: Sasha Levin commit 90ebddded536730153691b175ddfd63943c67a21 Author: Rob Herring (Arm) Date: Wed Jun 26 16:32:25 2024 -0600 perf: arm_pmuv3: Avoid assigning fixed cycle counter with threshold [ Upstream commit 81e15ca3e523a508d62806fe681c1d289361ca16 ] If the user has requested a counting threshold for the CPU cycles event, then the fixed cycle counter can't be assigned as it lacks threshold support. Currently, the thresholds will work or not randomly depending on which counter the event is assigned. While using thresholds for CPU cycles doesn't make much sense, it can be useful for testing purposes. Fixes: 816c26754447 ("arm64: perf: Add support for event counting threshold") Signed-off-by: Rob Herring (Arm) Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20240626-arm-pmu-3-9-icntr-v2-1-c9784b4f4065@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 269535618c16158f8eb1db4b50d02f5277c8ba97 Author: Christoph Hellwig Date: Tue Jun 25 07:52:38 2024 +0200 xen-blkfront: fix sector_size propagation to the block layer [ Upstream commit 98d34c087249d39838874b83e17671e7d5eb1ca7 ] Ensure that info->sector_size and info->physical_sector_size are set before the call to blkif_set_queue_limits by doing away with the local variables and arguments that propagate them. Thanks to Marek Marczykowski-Górecki and Jürgen Groß for root causing the issue. Fixes: ba3f67c11638 ("xen-blkfront: atomically update queue limits") Reported-by: Rusty Bird Signed-off-by: Christoph Hellwig Reviewed-by: Roger Pau Monné Link: https://lore.kernel.org/r/20240625055238.7934-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 28f7a3403100b224f91478064e40ae58681e5bcd Author: Bart Van Assche Date: Thu May 9 10:01:49 2024 -0700 block/mq-deadline: Fix the tag reservation code [ Upstream commit 39823b47bbd40502632ffba90ebb34fff7c8b5e8 ] The current tag reservation code is based on a misunderstanding of the meaning of data->shallow_depth. Fix the tag reservation code as follows: * By default, do not reserve any tags for synchronous requests because for certain use cases reserving tags reduces performance. See also Harshit Mogalapalli, [bug-report] Performance regression with fio sequential-write on a multipath setup, 2024-03-07 (https://lore.kernel.org/linux-block/5ce2ae5d-61e2-4ede-ad55-551112602401@oracle.com/) * Reduce min_shallow_depth to one because min_shallow_depth must be less than or equal any shallow_depth value. * Scale dd->async_depth from the range [1, nr_requests] to [1, bits_per_sbitmap_word]. Cc: Christoph Hellwig Cc: Damien Le Moal Cc: Zhiguo Niu Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests") Signed-off-by: Bart Van Assche Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240509170149.7639-3-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 136598536aaa8da361d1abf808e8c26dd162c7e5 Author: Bart Van Assche Date: Thu May 9 10:01:48 2024 -0700 block: Call .limit_depth() after .hctx has been set [ Upstream commit 6259151c04d4e0085e00d2dcb471ebdd1778e72e ] Call .limit_depth() after data->hctx has been set such that data->hctx can be used in .limit_depth() implementations. Cc: Christoph Hellwig Cc: Damien Le Moal Cc: Zhiguo Niu Fixes: 07757588e507 ("block/mq-deadline: Reserve 25% of scheduler tags for synchronous requests") Signed-off-by: Bart Van Assche Tested-by: Zhiguo Niu Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20240509170149.7639-2-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 515278065c7028c598c176f7eb9cd12159039dcc Author: Wayne Tung Date: Mon Jul 1 15:32:52 2024 +0800 hwmon: (adt7475) Fix default duty on fan is disabled [ Upstream commit 39b24cced70fdc336dbc0070f8b3bde61d8513a8 ] According to the comments on fan is disabled, we change to manual mode and set the duty cycle to 0. For setting the duty cycle part, the register is wrong. Fix it. Fixes: 1c301fc5394f ("hwmon: Add a driver for the ADT7475 hardware monitoring chip") Signed-off-by: Wayne Tung Link: https://lore.kernel.org/r/20240701073252.317397-1-chineweff@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 29ac1d238b3bf126af36037df80d7ecc4822341e Author: Chen Ridong Date: Fri Jun 28 01:36:04 2024 +0000 cgroup/cpuset: Prevent UAF in proc_cpuset_show() [ Upstream commit 1be59c97c83ccd67a519d8a49486b3a8a73ca28a ] An UAF can happen when /proc/cpuset is read as reported in [1]. This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc//cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc//cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..); When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces") Signed-off-by: Chen Ridong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f38d2e92149965b09feb1b0dcc22b40122ab262b Author: Josh Poimboeuf Date: Tue Jun 25 23:02:00 2024 -0700 x86/syscall: Mark exit[_group] syscall handlers __noreturn [ Upstream commit 9142be9e6443fd641ca37f820efe00d9cd890eb1 ] The direct-call syscall dispatch function doesn't know that the exit() and exit_group() syscall handlers don't return, so the call sites aren't optimized accordingly. Fix that by marking the exit syscall declarations __noreturn. Fixes the following warnings: vmlinux.o: warning: objtool: x64_sys_call+0x2804: __x64_sys_exit() is missing a __noreturn annotation vmlinux.o: warning: objtool: ia32_sys_call+0x29b6: __ia32_sys_exit_group() is missing a __noreturn annotation Fixes: 1e3ad78334a6 ("x86/syscall: Don't force use of indirect calls for system calls") Closes: https://lkml.kernel.org/lkml/6dba9b32-db2c-4e6d-9500-7a08852f17a3@paulmck-laptop Reported-by: Paul E. McKenney Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov (AMD) Tested-by: Paul E. McKenney Link: https://lore.kernel.org/r/5d8882bc077d8eadcc7fd1740b56dfb781f12288.1719381528.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin commit 70035fdfa8354a2e4febb8bf6b05d481273ec44d Author: Ilpo Järvinen Date: Mon May 27 15:55:38 2024 +0300 x86/platform/iosf_mbi: Convert PCIBIOS_* return codes to errnos [ Upstream commit 7821fa101eab529521aa4b724bf708149d70820c ] iosf_mbi_pci_{read,write}_mdr() use pci_{read,write}_config_dword() that return PCIBIOS_* codes but functions also return -ENODEV which are not compatible error codes. As neither of the functions are related to PCI read/write functions, they should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 46184415368a ("arch: x86: New MailBox support driver for Intel SOC's") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240527125538.13620-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 590c9a8348f97d62bc810a567c9c724d01edddec Author: Ilpo Järvinen Date: Mon May 27 15:55:37 2024 +0300 x86/pci/xen: Fix PCIBIOS_* return code handling [ Upstream commit e9d7b435dfaec58432f4106aaa632bf39f52ce9f ] xen_pcifront_enable_irq() uses pci_read_config_byte() that returns PCIBIOS_* codes. The error handling, however, assumes the codes are normal errnos because it checks for < 0. xen_pcifront_enable_irq() also returns the PCIBIOS_* code back to the caller but the function is used as the (*pcibios_enable_irq) function which should return normal errnos. Convert the error check to plain non-zero check which works for PCIBIOS_* return codes and convert the PCIBIOS_* return code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 3f2a230caf21 ("xen: handled remapped IRQs when enabling a pcifront PCI device.") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20240527125538.13620-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 32adc6914bb18edad6cbe42d1dd759ed9e62b7a3 Author: Ilpo Järvinen Date: Mon May 27 15:55:36 2024 +0300 x86/pci/intel_mid_pci: Fix PCIBIOS_* return code handling [ Upstream commit 724852059e97c48557151b3aa4af424614819752 ] intel_mid_pci_irq_enable() uses pci_read_config_byte() that returns PCIBIOS_* codes. The error handling, however, assumes the codes are normal errnos because it checks for < 0. intel_mid_pci_irq_enable() also returns the PCIBIOS_* code back to the caller but the function is used as the (*pcibios_enable_irq) function which should return normal errnos. Convert the error check to plain non-zero check which works for PCIBIOS_* return codes and convert the PCIBIOS_* return code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 5b395e2be6c4 ("x86/platform/intel-mid: Make IRQ allocation a bit more flexible") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240527125538.13620-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 0cee39aa04eecba02ea7ffca1662e63ca720bc6f Author: Ilpo Järvinen Date: Mon May 27 15:55:35 2024 +0300 x86/of: Return consistent error type from x86_of_pci_irq_enable() [ Upstream commit ec0b4c4d45cf7cf9a6c9626a494a89cb1ae7c645 ] x86_of_pci_irq_enable() returns PCIBIOS_* code received from pci_read_config_byte() directly and also -EINVAL which are not compatible error types. x86_of_pci_irq_enable() is used as (*pcibios_enable_irq) function which should not return PCIBIOS_* codes. Convert the PCIBIOS_* return code from pci_read_config_byte() into normal errno using pcibios_err_to_errno(). Fixes: 96e0a0797eba ("x86: dtb: Add support for PCI devices backed by dtb nodes") Signed-off-by: Ilpo Järvinen Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240527125538.13620-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Sasha Levin commit 312d272dc47aeb53097e76765c98b21ace9f9084 Author: Chao Yu Date: Fri Jun 7 22:23:04 2024 +0800 hfsplus: fix to avoid false alarm of circular locking [ Upstream commit be4edd1642ee205ed7bbf66edc0453b1be1fb8d7 ] Syzbot report potential ABBA deadlock as below: loop0: detected capacity change from 0 to 1024 ====================================================== WARNING: possible circular locking dependency detected 6.9.0-syzkaller-10323-g8f6a15f095a6 #0 Not tainted ------------------------------------------------------ syz-executor171/5344 is trying to acquire lock: ffff88807cb980b0 (&tree->tree_lock){+.+.}-{3:3}, at: hfsplus_file_truncate+0x811/0xb50 fs/hfsplus/extents.c:595 but task is already holding lock: ffff88807a930108 (&HFSPLUS_I(inode)->extents_lock){+.+.}-{3:3}, at: hfsplus_file_truncate+0x2da/0xb50 fs/hfsplus/extents.c:576 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&HFSPLUS_I(inode)->extents_lock){+.+.}-{3:3}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 hfsplus_file_extend+0x21b/0x1b70 fs/hfsplus/extents.c:457 hfsplus_bmap_reserve+0x105/0x4e0 fs/hfsplus/btree.c:358 hfsplus_rename_cat+0x1d0/0x1050 fs/hfsplus/catalog.c:456 hfsplus_rename+0x12e/0x1c0 fs/hfsplus/dir.c:552 vfs_rename+0xbdb/0xf00 fs/namei.c:4887 do_renameat2+0xd94/0x13f0 fs/namei.c:5044 __do_sys_rename fs/namei.c:5091 [inline] __se_sys_rename fs/namei.c:5089 [inline] __x64_sys_rename+0x86/0xa0 fs/namei.c:5089 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&tree->tree_lock){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 hfsplus_file_truncate+0x811/0xb50 fs/hfsplus/extents.c:595 hfsplus_setattr+0x1ce/0x280 fs/hfsplus/inode.c:265 notify_change+0xb9d/0xe70 fs/attr.c:497 do_truncate+0x220/0x310 fs/open.c:65 handle_truncate fs/namei.c:3308 [inline] do_open fs/namei.c:3654 [inline] path_openat+0x2a3d/0x3280 fs/namei.c:3807 do_filp_open+0x235/0x490 fs/namei.c:3834 do_sys_openat2+0x13e/0x1d0 fs/open.c:1406 do_sys_open fs/open.c:1421 [inline] __do_sys_creat fs/open.c:1497 [inline] __se_sys_creat fs/open.c:1491 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1491 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&HFSPLUS_I(inode)->extents_lock); lock(&tree->tree_lock); lock(&HFSPLUS_I(inode)->extents_lock); lock(&tree->tree_lock); This is a false alarm as tree_lock mutex are different, one is from sbi->cat_tree, and another is from sbi->ext_tree: Thread A Thread B - hfsplus_rename - hfsplus_rename_cat - hfs_find_init - mutext_lock(cat_tree->tree_lock) - hfsplus_setattr - hfsplus_file_truncate - mutex_lock(hip->extents_lock) - hfs_find_init - mutext_lock(ext_tree->tree_lock) - hfs_bmap_reserve - hfsplus_file_extend - mutex_lock(hip->extents_lock) So, let's call mutex_lock_nested for tree_lock mutex lock, and pass correct lock class for it. Fixes: 31651c607151 ("hfsplus: avoid deadlock on file truncation") Reported-by: syzbot+6030b3b1b9bf70e538c4@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-fsdevel/000000000000e37a4005ef129563@google.com Cc: Ernesto A. Fernández Signed-off-by: Chao Yu Link: https://lore.kernel.org/r/20240607142304.455441-1-chao@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 72b7a3b3268e6448715b72eb32ebb67f0f0351b2 Author: Masahiro Yamada Date: Wed Jun 12 14:02:55 2024 +0900 x86/kconfig: Add as-instr64 macro to properly evaluate AS_WRUSS [ Upstream commit 469169803d52a5d8f0dc781090638e851a7d22b1 ] Some instructions are only available on the 64-bit architecture. Bi-arch compilers that default to -m32 need the explicit -m64 option to evaluate them properly. Fixes: 18e66b695e78 ("x86/shstk: Add Kconfig option for shadow stack") Closes: https://lore.kernel.org/all/20240612-as-instr-opt-wrussq-v2-1-bd950f7eead7@gmail.com/ Reported-by: Dmitry Safonov <0x7f454c46@gmail.com> Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Tested-by: Dmitry Safonov <0x7f454c46@gmail.com> Link: https://lore.kernel.org/r/20240612050257.3670768-1-masahiroy@kernel.org Signed-off-by: Sasha Levin commit c3241416452806cce2e9f7fe6fec0518d819a4b7 Author: Waiman Long Date: Mon Jun 17 10:39:41 2024 -0400 cgroup/cpuset: Fix remote root partition creation problem [ Upstream commit ccac8e8de99cbcf5e7f53251ebce917bf7bcc29c ] Since commit 181c8e091aae ("cgroup/cpuset: Introduce remote partition"), a remote partition can be created underneath a non-partition root cpuset as long as its exclusive_cpus are set to distribute exclusive CPUs down to its children. The generate_sched_domains() function, however, doesn't take into account this new behavior and hence will fail to create the sched domain needed for a remote root (non-isolated) partition. There are two issues related to remote partition support. First of all, generate_sched_domains() has a fast path that is activated if root_load_balance is true and top_cpuset.nr_subparts is non-zero. The later condition isn't quite correct for remote partitions as nr_subparts just shows the number of local child partitions underneath it. There can be no local child partition under top_cpuset even if there are remote partitions further down the hierarchy. Fix that by checking for subpartitions_cpus which contains exclusive CPUs allocated to both local and remote partitions. Secondly, the valid partition check for subtree skipping in the csa[] generation loop isn't enough as remote partition does not need to have a partition root parent. Fix this problem by breaking csa[] array generation loop of generate_sched_domains() into v1 and v2 specific parts and checking a cpuset's exclusive_cpus before skipping its subtree in the v2 case. Also simplify generate_sched_domains() for cgroup v2 as only non-isolating partition roots should be included in building the cpuset array and none of the v1 scheduling attributes other than a different way to create an isolated partition are supported. Fixes: 181c8e091aae ("cgroup/cpuset: Introduce remote partition") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit b17f8733d51180f027a9009327150325ec06e9a8 Author: Waiman Long Date: Mon Jun 3 15:38:22 2024 -0400 cgroup/cpuset: Optimize isolated partition only generate_sched_domains() calls [ Upstream commit 1805c1729f52edaa021288473b09f9c7f74fb1ca ] If only isolated partitions are being created underneath the cgroup root, there will only be one sched domain with top_cpuset.effective_cpus. We can skip the unnecessary sched domains scanning code and save some cycles. Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Stable-dep-of: ccac8e8de99c ("cgroup/cpuset: Fix remote root partition creation problem") Signed-off-by: Sasha Levin commit 7703ee4c86c922e2b69d3b0d42ded1c4401529ab Author: Gabriel Krisman Bertazi Date: Tue Jun 18 22:06:18 2024 -0400 io_uring: Fix probe of disabled operations [ Upstream commit 3e05b222382ec67dce7358d50b6006e91d028d8b ] io_probe checks io_issue_def->not_supported, but we never really set that field, as we mark non-supported functions through a specific ->prep handler. This means we end up returning IO_URING_OP_SUPPORTED, even for disabled operations. Fix it by just checking the prep handler itself. Fixes: 66f4af93da57 ("io_uring: add support for probing opcodes") Signed-off-by: Gabriel Krisman Bertazi Link: https://lore.kernel.org/r/20240619020620.5301-2-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 47149c165a6faa253e21683e10b4d3fa56e5992c Author: Damien Le Moal Date: Tue Jun 11 11:36:37 2024 +0900 dm: Call dm_revalidate_zones() after setting the queue limits [ Upstream commit 7f91ccd8a608dbe39b97a6e43d635378d493f77e ] dm_revalidate_zones() is called from dm_set_zone_restrictions() when the mapped device queue limits are not yet set. However, dm_revalidate_zones() calls blk_revalidate_disk_zones() and this function consults and modifies the mapped device queue limits. Thus, currently, blk_revalidate_disk_zones() operates on limits that are not yet initialized. Fix this by moving the call to dm_revalidate_zones() out of dm_set_zone_restrictions() and into dm_table_set_restrictions() after executing queue_limits_set(). To further cleanup dm_set_zones_restrictions(), the message about the type of zone append (native or emulated) is also moved inside dm_revalidate_zones(). Fixes: 1c0e720228ad ("dm: use queue_limits_set") Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Benjamin Marzinski Reviewed-by: Niklas Cassel Link: https://lore.kernel.org/r/20240611023639.89277-3-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ebc0e91ba76dc6544fff9f5b66408b1982806a00 Author: Christoph Hellwig Date: Thu Jun 13 10:48:11 2024 +0200 block: initialize integrity buffer to zero before writing it to media [ Upstream commit 899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f ] Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. Fixes: 7ba1ba12eeef ("block: Block layer data integrity support") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: Kanchan Joshi Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20240613084839.1044015-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5535adc933fb2362ba20659f2aa64b5f9ddd41fe Author: Christoph Hellwig Date: Fri May 31 09:47:57 2024 +0200 ubd: untagle discard vs write zeroes not support handling [ Upstream commit 31ade7d4fdcf382beb8cb229a1f5d77e0f239672 ] Discard and Write Zeroes are different operation and implemented by different fallocate opcodes for ubd. If one fails the other one can work and vice versa. Split the code to disable the operations in ubd_handler to only disable the operation that actually failed. Fixes: 50109b5a03b4 ("um: Add support for DISCARD in the UBD Driver") Signed-off-by: Christoph Hellwig Reviewed-by: Bart Van Assche Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Acked-By: Anton Ivanov Link: https://lore.kernel.org/r/20240531074837.1648501-3-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 49d7da56f1d9560616e38252c57785a12f6974d8 Author: Christoph Hellwig Date: Fri May 31 09:47:56 2024 +0200 ubd: refactor the interrupt handler [ Upstream commit 5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6 ] Instead of a separate handler function that leaves no work in the interrupt hanler itself, split out a per-request end I/O helper and clean up the coding style and variable naming while we're at it. Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Acked-By: Anton Ivanov Link: https://lore.kernel.org/r/20240531074837.1648501-2-hch@lst.de Signed-off-by: Jens Axboe Stable-dep-of: 31ade7d4fdcf ("ubd: untagle discard vs write zeroes not support handling") Signed-off-by: Sasha Levin commit e2172a1397630aa1ef3ac46eed73e78525b0c99c Author: Tzung-Bi Shih Date: Tue Jun 11 11:31:10 2024 +0000 platform/chrome: cros_ec_debugfs: fix wrong EC message version [ Upstream commit c2a28647bbb4e0894e8824362410f72b06ac57a4 ] ec_read_version_supported() uses ec_params_get_cmd_versions_v1 but it wrongly uses message version 0. Fix it. Fixes: e86264595225 ("mfd: cros_ec: add debugfs, console log file") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20240611113110.16955-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin commit 6bb2fccb2cb7e276445affbcf673b7902cc5ee1c Author: Christoph Hellwig Date: Tue Jun 4 19:25:29 2024 +0200 md/raid1: don't free conf on raid0_run failure [ Upstream commit 17f91ac0843b50462a9c9c8f18df962338bd3db2 ] The core md code calls the ->free method which already frees conf. Fixes: 07f1a6850c5d ("md/raid1: fail run raid1 array when active disk less than one") Signed-off-by: Christoph Hellwig Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240604172607.3185916-3-hch@lst.de Signed-off-by: Sasha Levin commit 7526c725d51200aab2ee0ee8c44808873c965ddb Author: Christoph Hellwig Date: Tue Jun 4 19:25:28 2024 +0200 md/raid0: don't free conf on raid0_run failure [ Upstream commit 35f20acaa3585f25f8356da0ee6bc143e0256522 ] The core md code calls the ->free method which already frees conf. Fixes: 0c031fd37f69 ("md: Move alloc/free acct bioset in to personality") Signed-off-by: Christoph Hellwig Reviewed-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240604172607.3185916-2-hch@lst.de Signed-off-by: Sasha Levin commit ca963eefbc3331222b6121baa696d49ba2008811 Author: Li Nan Date: Sun May 26 02:52:57 2024 +0800 md: fix deadlock between mddev_suspend and flush bio [ Upstream commit 611d5cbc0b35a752e657a83eebadf40d814d006b ] Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context. Fixes: fa2bbff7b0b4 ("md: synchronize flush io with array reconfiguration") Signed-off-by: Li Nan Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240525185257.3896201-3-linan666@huaweicloud.com Signed-off-by: Sasha Levin commit af594a0bb5c80c6bba634174f0940d78b917b7f9 Author: Frederic Weisbecker Date: Fri May 17 17:23:02 2024 +0200 rcu/tasks: Fix stale task snaphot for Tasks Trace [ Upstream commit 399ced9594dfab51b782798efe60a2376cd5b724 ] When RCU-TASKS-TRACE pre-gp takes a snapshot of the current task running on all online CPUs, no explicit ordering synchronizes properly with a context switch. This lack of ordering can permit the new task to miss pre-grace-period update-side accesses. The following diagram, courtesy of Paul, shows the possible bad scenario: CPU 0 CPU 1 ----- ----- // Pre-GP update side access WRITE_ONCE(*X, 1); smp_mb(); r0 = rq->curr; RCU_INIT_POINTER(rq->curr, TASK_B) spin_unlock(rq) rcu_read_lock_trace() r1 = X; /* ignore TASK_B */ Either r0==TASK_B or r1==1 is needed but neither is guaranteed. One possible solution to solve this is to wait for an RCU grace period at the beginning of the RCU-tasks-trace grace period before taking the current tasks snaphot. However this would introduce large additional latencies to RCU-tasks-trace grace periods. Another solution is to lock the target runqueue while taking the current task snapshot. This ensures that the update side sees the latest context switch and subsequent context switches will see the pre-grace-period update side accesses. This commit therefore adds runqueue locking to cpu_curr_snapshot(). Fixes: e386b6725798 ("rcu-tasks: Eliminate RCU Tasks Trace IPIs to online CPUs") Signed-off-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 32700ecf8007e071d1ce4c78f65b85f46d05f32a Author: Arnd Bergmann Date: Wed May 29 11:51:11 2024 +0200 EDAC, i10nm: make skx_common.o a separate module [ Upstream commit 123b158635505c89ed0d3ef45c5845ff9030a466 ] Commit 598afa050403 ("kbuild: warn objects shared among multiple modules") was added to track down cases where the same object is linked into multiple modules. This can cause serious problems if some modules are builtin while others are not. That test triggers this warning: scripts/Makefile.build:236: drivers/edac/Makefile: skx_common.o is added to multiple modules: i10nm_edac skx_edac Make this a separate module instead. [Tony: Added more background details to commit message] Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors") Signed-off-by: Arnd Bergmann Signed-off-by: Tony Luck Link: https://lore.kernel.org/all/20240529095132.1929397-1-arnd@kernel.org/ Signed-off-by: Sasha Levin commit 24468dbfec0532705c37c60d618e87f798f8bc40 Author: Chen Ni Date: Wed May 15 16:40:28 2024 +0800 spi: atmel-quadspi: Add missing check for clk_prepare [ Upstream commit ef901b38d3a4610c4067cd306c1a209f32e7ca31 ] Add check for the return value of clk_prepare() and return the error if it fails in order to catch the error. Fixes: 4a2f83b7f780 ("spi: atmel-quadspi: add runtime pm support") Signed-off-by: Chen Ni Link: https://msgid.link/r/20240515084028.3210406-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 949676eb8a4d911efb3988a9e4a2d3e27ec026bd Author: Prajna Rajendra Kumar Date: Tue May 14 11:45:07 2024 +0100 spi: spi-microchip-core: Fix the number of chip selects supported [ Upstream commit a7ed3a11202d90939a3d00ffcc8cf50703cb7b35 ] The SPI "hard" controller in PolarFire SoC has eight CS lines, but only one CS line is wired. When the 'num-cs' property is not specified in the device tree, the driver defaults to the MAX_CS value, which has been fixed to 1 to match the hardware configuration; however, when the 'num-cs' property is explicitly defined in the device tree, it overrides the default value. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Prajna Rajendra Kumar Reviewed-by: Conor Dooley Link: https://msgid.link/r/20240514104508.938448-3-prajna.rajendrakumar@microchip.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin