summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-09-05Merge branches 'amba' and 'misc' into for-linusRussell King (Oracle)
2024-09-05platform/x86: wmi: Call both legacy and WMI driver notify handlersArmin Wolf
Since the legacy WMI notify handlers are now using the WMI event data provided by the WMI driver core, they can coexist with modern WMI driver notify handlers. Remove the precedence of WMI driver notify handlers and call both when receiving an event. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240901031055.3030-6-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-09-05platform/x86: wmi: Merge get_event_data() with wmi_get_notify_data()Armin Wolf
Since get_event_data() is only called by wmi_get_notify_data(), it makes sense to merge both functions. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240901031055.3030-5-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-09-05platform/x86: wmi: Remove wmi_get_event_data()Armin Wolf
Since the WMI driver core now takes care of retrieving the WMI event data even for legacy WMI notify handlers, this function is no longer used. Remove it to prevent WMI drivers from messing up the ACPI firmware on some machines. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240901031055.3030-4-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-09-05platform/x86: wmi: Pass event data directly to legacy notify handlersArmin Wolf
The current legacy WMI handlers are susceptible to picking up wrong WMI event data on systems where different WMI devices share some notification IDs. Prevent this by letting the WMI driver core taking care of retrieving the event data. This also simplifies the legacy WMI handlers and their implementation inside the WMI driver core. Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20240901031055.3030-3-W_Armin@gmx.de Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2024-09-05bus: sunxi-rsb: Simplify code with dev_err_probe()Zhang Zekun
Use dev_err_probe() directly in the driver probe phase. This can simplify the code a bit. Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com> Link: https://lore.kernel.org/r/20240905114134.80310-1-zhangzekun11@huawei.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-09-05dt: dt-extract-compatibles: Extract compatibles from function parametersRob Herring (Arm)
Various DT and fwnode functions take a compatible string as a parameter. These are often used in cases which don't have a driver, so they've been missed. The additional checks add about 400 more undocumented compatible strings. Link: https://lore.kernel.org/all/20240903200753.2097911-1-robh@kernel.org/ Acked-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-09-05iommu/tegra241-cmdqv: Do not allocate vcmdq until dma_set_mask_and_coherentNicolin Chen
It's observed that, when the first 4GB of system memory was reserved, all VCMDQ allocations failed (even with the smallest qsz in the last attempt): arm-smmu-v3: found companion CMDQV device: NVDA200C:00 arm-smmu-v3: option mask 0x10 arm-smmu-v3: failed to allocate queue (0x8000 bytes) for vcmdq0 acpi NVDA200C:00: tegra241_cmdqv: Falling back to standard SMMU CMDQ arm-smmu-v3: ias 48-bit, oas 48-bit (features 0x001e1fbf) arm-smmu-v3: allocated 524288 entries for cmdq arm-smmu-v3: allocated 524288 entries for evtq arm-smmu-v3: allocated 524288 entries for priq This is because the 4GB reserved memory shifted the entire DMA zone from a lower 32-bit range (on a system without the 4GB carveout) to higher range, while the dev->coherent_dma_mask was set to DMA_BIT_MASK(32) by default. The dma_set_mask_and_coherent() call is done in arm_smmu_device_hw_probe() of the SMMU driver. So any DMA allocation from tegra241_cmdqv_probe() must wait until the coherent_dma_mask is correctly set. Move the vintf/vcmdq structure initialization routine into a different op, "init_structures". Call it at the end of arm_smmu_init_structures(), where standard SMMU queues get allocated. Most of the impl_ops aren't ready until vintf/vcmdq structure are init-ed. So replace the full impl_ops with an init_ops in __tegra241_cmdqv_probe(). And switch to tegra241_cmdqv_impl_ops later in arm_smmu_init_structures(). Note that tegra241_cmdqv_impl_ops does not link to the new init_structures op after this switch, since there is no point in having it once it's done. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Reported-by: Matt Ochs <mochs@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/530993c3aafa1b0fc3d879b8119e13c629d12e2b.1725503154.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-05iommu/tegra241-cmdqv: Drop static at local variableNicolin Chen
This is likely a typo. Drop it. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/13fd3accb5b7ed6ec11cc6b7435f79f84af9f45f.1725503154.git.nicolinc@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-09-05spi: fspi: add support for imx8ulpHaibo Chen
The flexspi on imx8ulp only has 16 LUTs, different with others which have up to 32 LUTs. Add a separate compatible string and nxp_fspi_devtype_data to support flexspi on imx8ulp. Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node") Cc: stable@kernel.org Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20240905094338.1986871-4-haibo.chen@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-05spi: fspi: involve lut_num for struct nxp_fspi_devtype_dataHaibo Chen
The flexspi on different SoCs may have different number of LUTs. So involve lut_num in nxp_fspi_devtype_data to make distinguish. This patch prepare for the adding of imx8ulp. Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node") Cc: stable@kernel.org Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20240905094338.1986871-3-haibo.chen@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-05dt-bindings: spi: nxp-fspi: add imx8ulp supportHaibo Chen
The flexspi on imx8ulp only has 16 number of LUTs, it is different with flexspi on other imx SoC which has 32 number of LUTs. Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node") Cc: stable@kernel.org Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20240905094338.1986871-2-haibo.chen@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-05ASoC: Intel: skl_hda_dsp_generic: convert comma to semicolonChen Ni
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20240905022017.1642550-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-05ASoC: topology-test: Convert comma to semicolonChen Ni
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20240905032148.1929393-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2024-09-05hv: vmbus: Constify struct kobj_type and struct attribute_groupHongbo Li
vmbus_chan_group and vmbus_chan_type are not modified. They are only used in the helpers which take a const type parameter. Constifying these structures and moving them to a read-only section can increase over all security. ``` [Before] text data bss dec hex filename 20568 4699 48 25315 62e3 drivers/hv/vmbus_drv.o [After] text data bss dec hex filename 20696 4571 48 25315 62e3 drivers/hv/vmbus_drv.o ``` Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Reviewed-by: Naman Jain <namjain@linux.microsoft.com> Link: https://lore.kernel.org/r/20240904011553.2010203-1-lihongbo22@huawei.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20240904011553.2010203-1-lihongbo22@huawei.com>
2024-09-05Merge tag 'hwmon-for-v6.11-rc7' into review-hansHans de Goede
Merge "hwmon fixes for v6.11-rc7" into review-hans to bring in commit a54da9df75cd ("hwmon: (hp-wmi-sensors) Check if WMI event data exists"). This is a dependency for a set of WMI event data refactoring changes.
2024-09-05EDAC: Drop obsolete PPC4xx driverRob Herring (Arm)
Since 47d13a269bbd ("powerpc/40x: Remove 40x platforms.") support for PPC40x platforms has been removed. While the EDAC driver also mentions PPC440 and PPC460 processors, the driver refuses to probe on anything other than PPC405. It's unlikely support will ever be added at this point for these other old platforms, so the driver can be removed. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Link: https://lore.kernel.org/r/20240904192224.3060307-2-robh@kernel.org
2024-09-05uprobes: perform lockless SRCU-protected uprobes_tree lookupAndrii Nakryiko
Another big bottleneck to scalablity is uprobe_treelock that's taken in a very hot path in handle_swbp(). Now that uprobes are SRCU-protected, take advantage of that and make uprobes_tree RB-tree look up lockless. To make RB-tree RCU-protected lockless lookup correct, we need to take into account that such RB-tree lookup can return false negatives if there are parallel RB-tree modifications (rotations) going on. We use seqcount lock to detect whether RB-tree changed, and if we find nothing while RB-tree got modified inbetween, we just retry. If uprobe was found, then it's guaranteed to be a correct lookup. With all the lock-avoiding changes done, we get a pretty decent improvement in performance and scalability of uprobes with number of CPUs, even though we are still nowhere near linear scalability. This is due to SRCU not really scaling very well with number of CPUs on a particular hardware that was used for testing (80-core Intel Xeon Gold 6138 CPU @ 2.00GHz), but also due to the remaning mmap_lock, which is currently taken to resolve interrupt address to inode+offset and then uprobe instance. And, of course, uretprobes still need similar RCU to avoid refcount in the hot path, which will be addressed in the follow up patches. Nevertheless, the improvement is good. We used BPF selftest-based uprobe-nop and uretprobe-nop benchmarks to get the below numbers, varying number of CPUs on which uprobes and uretprobes are triggered. BASELINE ======== uprobe-nop ( 1 cpus): 3.032 ± 0.023M/s ( 3.032M/s/cpu) uprobe-nop ( 2 cpus): 3.452 ± 0.005M/s ( 1.726M/s/cpu) uprobe-nop ( 4 cpus): 3.663 ± 0.005M/s ( 0.916M/s/cpu) uprobe-nop ( 8 cpus): 3.718 ± 0.038M/s ( 0.465M/s/cpu) uprobe-nop (16 cpus): 3.344 ± 0.008M/s ( 0.209M/s/cpu) uprobe-nop (32 cpus): 2.288 ± 0.021M/s ( 0.071M/s/cpu) uprobe-nop (64 cpus): 3.205 ± 0.004M/s ( 0.050M/s/cpu) uretprobe-nop ( 1 cpus): 1.979 ± 0.005M/s ( 1.979M/s/cpu) uretprobe-nop ( 2 cpus): 2.361 ± 0.005M/s ( 1.180M/s/cpu) uretprobe-nop ( 4 cpus): 2.309 ± 0.002M/s ( 0.577M/s/cpu) uretprobe-nop ( 8 cpus): 2.253 ± 0.001M/s ( 0.282M/s/cpu) uretprobe-nop (16 cpus): 2.007 ± 0.000M/s ( 0.125M/s/cpu) uretprobe-nop (32 cpus): 1.624 ± 0.003M/s ( 0.051M/s/cpu) uretprobe-nop (64 cpus): 2.149 ± 0.001M/s ( 0.034M/s/cpu) SRCU CHANGES ============ uprobe-nop ( 1 cpus): 3.276 ± 0.005M/s ( 3.276M/s/cpu) uprobe-nop ( 2 cpus): 4.125 ± 0.002M/s ( 2.063M/s/cpu) uprobe-nop ( 4 cpus): 7.713 ± 0.002M/s ( 1.928M/s/cpu) uprobe-nop ( 8 cpus): 8.097 ± 0.006M/s ( 1.012M/s/cpu) uprobe-nop (16 cpus): 6.501 ± 0.056M/s ( 0.406M/s/cpu) uprobe-nop (32 cpus): 4.398 ± 0.084M/s ( 0.137M/s/cpu) uprobe-nop (64 cpus): 6.452 ± 0.000M/s ( 0.101M/s/cpu) uretprobe-nop ( 1 cpus): 2.055 ± 0.001M/s ( 2.055M/s/cpu) uretprobe-nop ( 2 cpus): 2.677 ± 0.000M/s ( 1.339M/s/cpu) uretprobe-nop ( 4 cpus): 4.561 ± 0.003M/s ( 1.140M/s/cpu) uretprobe-nop ( 8 cpus): 5.291 ± 0.002M/s ( 0.661M/s/cpu) uretprobe-nop (16 cpus): 5.065 ± 0.019M/s ( 0.317M/s/cpu) uretprobe-nop (32 cpus): 3.622 ± 0.003M/s ( 0.113M/s/cpu) uretprobe-nop (64 cpus): 3.723 ± 0.002M/s ( 0.058M/s/cpu) Peak througput increased from 3.7 mln/s (uprobe triggerings) up to about 8 mln/s. For uretprobes it's a bit more modest with bump from 2.4 mln/s to 5mln/s. Suggested-by: "Peter Zijlstra (Intel)" <peterz@infradead.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-8-andrii@kernel.org
2024-09-05rbtree: provide rb_find_rcu() / rb_find_add_rcu()Peter Zijlstra
Much like latch_tree, add two RCU methods for the regular RB-tree, which can be used in conjunction with a seqcount to provide lockless lookups. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: "Masami Hiramatsu (Google)" <mhiramat@kernel.org> Link: https://lore.kernel.org/r/20240903174603.3554182-7-andrii@kernel.org
2024-09-05perf/uprobe: split uprobe_unregister()Peter Zijlstra
With uprobe_unregister() having grown a synchronize_srcu(), it becomes fairly slow to call. Esp. since both users of this API call it in a loop. Peel off the sync_srcu() and do it once, after the loop. We also need to add uprobe_unregister_sync() into uprobe_register()'s error handling path, as we need to be careful about returning to the caller before we have a guarantee that partially attached consumer won't be called anymore. This is an unlikely slow path and this should be totally fine to be slow in the case of a failed attach. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org> Co-developed-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-6-andrii@kernel.org
2024-09-05uprobes: travers uprobe's consumer list locklessly under SRCU protectionAndrii Nakryiko
uprobe->register_rwsem is one of a few big bottlenecks to scalability of uprobes, so we need to get rid of it to improve uprobe performance and multi-CPU scalability. First, we turn uprobe's consumer list to a typical doubly-linked list and utilize existing RCU-aware helpers for traversing such lists, as well as adding and removing elements from it. For entry uprobes we already have SRCU protection active since before uprobe lookup. For uretprobe we keep refcount, guaranteeing that uprobe won't go away from under us, but we add SRCU protection around consumer list traversal. Lastly, to keep handler_chain()'s UPROBE_HANDLER_REMOVE handling simple, we remember whether any removal was requested during handler calls, but then we double-check the decision under a proper register_rwsem using consumers' filter callbacks. Handler removal is very rare, so this extra lock won't hurt performance, overall, but we also avoid the need for any extra protection (e.g., seqcount locks). Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-5-andrii@kernel.org
2024-09-05uprobes: get rid of enum uprobe_filter_ctx in uprobe filter callbacksAndrii Nakryiko
It serves no purpose beyond adding unnecessray argument passed to the filter callback. Just get rid of it, no one is actually using it. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-4-andrii@kernel.org
2024-09-05uprobes: protected uprobe lifetime with SRCUAndrii Nakryiko
To avoid unnecessarily taking a (brief) refcount on uprobe during breakpoint handling in handle_swbp for entry uprobes, make find_uprobe() not take refcount, but protect the lifetime of a uprobe instance with RCU. This improves scalability, as refcount gets quite expensive due to cache line bouncing between multiple CPUs. Specifically, we utilize our own uprobe-specific SRCU instance for this RCU protection. put_uprobe() will delay actual kfree() using call_srcu(). For now, uretprobe and single-stepping handling will still acquire refcount as necessary. We'll address these issues in follow up patches by making them use SRCU with timeout. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-3-andrii@kernel.org
2024-09-05uprobes: revamp uprobe refcounting and lifetime managementAndrii Nakryiko
Revamp how struct uprobe is refcounted, and thus how its lifetime is managed. Right now, there are a few possible "owners" of uprobe refcount: - uprobes_tree RB tree assumes one refcount when uprobe is registered and added to the lookup tree; - while uprobe is triggered and kernel is handling it in the breakpoint handler code, temporary refcount bump is done to keep uprobe from being freed; - if we have uretprobe requested on a given struct uprobe instance, we take another refcount to keep uprobe alive until user space code returns from the function and triggers return handler. The uprobe_tree's extra refcount of 1 is confusing and problematic. No matter how many actual consumers are attached, they all share the same refcount, and we have an extra logic to drop the "last" (which might not really be last) refcount once uprobe's consumer list becomes empty. This is unconventional and has to be kept in mind as a special case all the time. Further, because of this design we have the situations where find_uprobe() will find uprobe, bump refcount, return it to the caller, but that uprobe will still need uprobe_is_active() check, after which the caller is required to drop refcount and try again. This is just too many details leaking to the higher level logic. This patch changes refcounting scheme in such a way as to not have uprobes_tree keeping extra refcount for struct uprobe. Instead, each uprobe_consumer is assuming its own refcount, which will be dropped when consumer is unregistered. Other than that, all the active users of uprobe (entry and return uprobe handling code) keeps exactly the same refcounting approach. With the above setup, once uprobe's refcount drops to zero, we need to make sure that uprobe's "destructor" removes uprobe from uprobes_tree, of course. This, though, races with uprobe entry handling code in handle_swbp(), which, through find_active_uprobe()->find_uprobe() lookup, can race with uprobe being destroyed after refcount drops to zero (e.g., due to uprobe_consumer unregistering). So we add try_get_uprobe(), which will attempt to bump refcount, unless it already is zero. Caller needs to guarantee that uprobe instance won't be freed in parallel, which is the case while we keep uprobes_treelock (for read or write, doesn't matter). Note also, we now don't leak the race between registration and unregistration, so we remove the retry logic completely. If find_uprobe() returns valid uprobe, it's guaranteed to remain in uprobes_tree with properly incremented refcount. The race is handled inside __insert_uprobe() and put_uprobe() working together: __insert_uprobe() will remove uprobe from RB-tree, if it can't bump refcount and will retry to insert the new uprobe instance. put_uprobe() won't attempt to remove uprobe from RB-tree, if it's already not there. All that is protected by uprobes_treelock, which keeps things simple. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://lore.kernel.org/r/20240903174603.3554182-2-andrii@kernel.org
2024-09-05bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()Oleg Nesterov
If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list. Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Closes: https://lore.kernel.org/all/000000000000382d39061f59f2dd@google.com/ Reported-by: syzbot+f7a1c2c2711e4a780f19@syzkaller.appspotmail.com Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Tested-by: syzbot+f7a1c2c2711e4a780f19@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240813152524.GA7292@redhat.com
2024-09-05perf/core: Fix small negative period being ignoredLuo Gengkun
In perf_adjust_period, we will first calculate period, and then use this period to calculate delta. However, when delta is less than 0, there will be a deviation compared to when delta is greater than or equal to 0. For example, when delta is in the range of [-14,-1], the range of delta = delta + 7 is between [-7,6], so the final value of delta/8 is 0. Therefore, the impact of -1 and -2 will be ignored. This is unacceptable when the target period is very short, because we will lose a lot of samples. Here are some tests and analyzes: before: # perf record -e cs -F 1000 ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.022 MB perf.data (518 samples) ] # perf script ... a.out 396 257.956048: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.957891: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.959730: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.961545: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.963355: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.965163: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.966973: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.968785: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.970593: 23 cs: ffffffff81f4eeec schedul> ... after: # perf record -e cs -F 1000 ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.058 MB perf.data (1466 samples) ] # perf script ... a.out 395 59.338813: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.339707: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.340682: 13 cs: ffffffff81f4eeec schedul> a.out 395 59.341751: 13 cs: ffffffff81f4eeec schedul> a.out 395 59.342799: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.343765: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.344651: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.345539: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.346502: 13 cs: ffffffff81f4eeec schedul> ... test.c int main() { for (int i = 0; i < 20000; i++) usleep(10); return 0; } # time ./a.out real 0m1.583s user 0m0.040s sys 0m0.298s The above results were tested on x86-64 qemu with KVM enabled using test.c as test program. Ideally, we should have around 1500 samples, but the previous algorithm had only about 500, whereas the modified algorithm now has about 1400. Further more, the new version shows 1 sample per 0.001s, while the previous one is 1 sample per 0.002s.This indicates that the new algorithm is more sensitive to small negative values compared to old algorithm. Fixes: bd2b5b12849a ("perf_counter: More aggressive frequency adjustment") Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20240831074316.2106159-2-luogengkun@huaweicloud.com
2024-09-05Merge tag 'nvme-6.11-2024-09-05' of git://git.infradead.org/nvme into block-6.11Jens Axboe
Pull NVMe fixes from Keith: "nvme fixes for Linux 6.11 - Sparse fix on static symbol (Jinjie) - Misleading warning message fix (Keith) - TCP command allocation handling fix (Maurizio) - PCI tagset allocation handling fix (Keith) - Low-power quirk for Samsung (Georg) - Queue limits fix for zone devices (Christoph) - Target protocol behavior fix (Maurizio)" * tag 'nvme-6.11-2024-09-05' of git://git.infradead.org/nvme: nvmet: Identify-Active Namespace ID List command should reject invalid nsid nvme: set BLK_FEAT_ZONED for ZNS multipath disks nvme-pci: Add sleep quirk for Samsung 990 Evo nvme-pci: allocate tagset on reset if necessary nvmet-tcp: fix kernel crash if commands allocation fails nvme: use better description for async reset reason nvmet: Make nvmet_debugfs static
2024-09-05Add audio support for the MediaTek Genio 350-evkMark Brown
Merge series from amergnat@baylibre.com: This serie aim to add the following audio support for the Genio 350-evk: - Playback - 2ch Headset Jack (Earphone) - 1ch Line-out Jack (Speaker) - 8ch HDMI Tx - Capture - 1ch DMIC (On-board Digital Microphone) - 1ch AMIC (On-board Analogic Microphone) - 1ch Headset Jack (External Analogic Microphone) Of course, HDMI playback need the MT8365 display patches [1] and a DTS change documented in "mediatek,mt8365-mt6357.yaml".
2024-09-05Merge tag 'amlogic-drivers-for-v6.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/drivers Amlogic drivers changes for v6.12: - Support new Amlogic SoCs in meson-gx-ao-secure & meson-gx-socinfo * tag 'amlogic-drivers-for-v6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: soc: amlogic: meson-gx-socinfo: add new SoCs id dt-bindings: arm: amlogic: meson-gx-ao-secure: support more SoCs Link: https://lore.kernel.org/r/577ad7fe-19b1-468a-b994-573855493fd7@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-09-05ARM: dts: Fix undocumented LM75 compatible nodesRob Herring
"lm75" without any vendor is undocumented. It works with the Linux kernel since the I2C subsystem will do matches of the compatible string without a vendor prefix to the i2c_device_id and/or driver name. Mostly replace "lm75" with "national,lm75" as that's the original part vendor and the compatible which matches what "lm75" matched with. In a couple of cases the node name or compatible gives a clue to the actual part and vendor and a more specific compatible can be used. In these cases, it does change the variant the kernel picks. "nct75" is an OnSemi part which is compatible with TI TMP75C based on a comparison of the OnSemi NCT75 datasheet and configuration the Linux driver uses. Adding an OnSemi compatible would be an ABI change. "nxp,lm75" is most likely an NXP part. Alexander Stein says the i.MX53 boards are a NXP LM75A as well. NXP makes a LM75A and LM75B. Both are 11-bit resolution and 100ms sample time. The "national,lm75a" is 9-bit, so "national,lm75b" is the closest match for both NXP variants. While we're here, fix the node names to use the generic name "temperature-sensor". Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Kevin Hilman <khilman@baylibre.com> # am335x-nano.dts Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> # imx53-mba53.dts, imx53-tqma53.dtsi Link: https://lore.kernel.org/r/20240816164717.1585629-1-robh@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-09-05power: supply: ab8500: Constify struct kobj_typeHongbo Li
This 'struct kobj_type' is not modified. It is only used in kobject_init_and_add() which takes a 'const struct kobj_type *ktype' parameter. Constifying this structure and moving it to a read-only section, and can increase over all security. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://lore.kernel.org/r/20240904011434.2010118-1-lihongbo22@huawei.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-09-05power: supply: max1720x: fix a double free on error in probe()Dan Carpenter
In this code, if devm_add_action_or_reset() fails, it will call max1720x_unregister_ancillary() which in turn calls i2c_unregister_device(). Thus the call to i2c_unregister_device() on the following line is not required and is a double unregister. Delete it. Fixes: 47271a935619 ("power: supply: max1720x: add read support for nvmem") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/9c2f76e7-5679-473b-9b9c-e11b492b96ac@stanley.mountain Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-09-05ALSA: hda/realtek - Fix inactive headset mic jack for ASUS Vivobook 15 X1504VAPVasiliy Kovalev
When the headset is connected, there is no automatic switching of the capture source - you can only manually select the headset microphone in pavucontrol. This patch fixes/activates the inactive microphone of the headset. Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org> Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20240905140211.937385-1-kovalev@altlinux.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-09-05Merge tag 'amlogic-arm64-dt-for-v6.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/dt Amlogic ARM64 DT changes for v6.12: - New Boards: - AW419 (Amlogic C3) - Power Controller node for Amlogic A5 SoC - Always-On Secure node for Amlogig A4/T7/C4 & S4 SoCs - Amlogic A4 & C3 hardware support: - PLL, SPICC, NOND, SDCard, Ethernet, Watchdog - Final fixes for DTBs check: - add clock and clock-names to sound cards - drop saradc gxlx compatible * tag 'amlogic-arm64-dt-for-v6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux: arm64: dts: amlogic: gxlx-s905l-p271: drop saradc gxlx compatible arm64: dts: amlogic: add clock and clock-names to sound cards arm64: dts: amlogic: c3: fix dtbcheck warning arm64: dts: amlogic: add C3 AW419 board arm64: dts: amlogic: add some device nodes for C3 dt-bindings: clock: fix C3 PLL input parameter arm64: dts: amlogic: a4: add ao secure node arm64: dts: amlogic: t7: add ao secure node arm64: dts: amlogic: c3: add ao secure node arm64: dts: amlogic: s4: add ao secure node arm64: dts: amlogic: add watchdog node for A4 SoCs arm64: dts: amlogic: enable some device nodes for S4 arm64: dts: amlogic: a5: add power domain controller node Link: https://lore.kernel.org/r/cc8fb460-5ac0-4b16-8490-8ac9f89f1b7f@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-09-05HID: uclogic: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-14-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: waltop: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-12-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: sony: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-11-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: pxrc: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-10-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: steelseries: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-9-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: viewsonic: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-8-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: vrc2: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-7-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: xiaomi: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-6-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: maltron: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-5-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: keytouch: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-4-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: holtek-kbd: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-3-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: dr: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-2-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05HID: bigbenff: constify fixed up report descriptorThomas Weißschuh
Now that the HID core can handle const report descriptors, constify them where possible. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20240828-hid-const-fixup-2-v1-1-663b9210eb69@weissschuh.net Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-09-05eventfs: Use list_del_rcu() for SRCU protected list variableSteven Rostedt
Chi Zhiling reported: We found a null pointer accessing in tracefs[1], the reason is that the variable 'ei_child' is set to LIST_POISON1, that means the list was removed in eventfs_remove_rec. so when access the ei_child->is_freed, the panic triggered. by the way, the following script can reproduce this panic loop1 (){ while true do echo "p:kp submit_bio" > /sys/kernel/debug/tracing/kprobe_events echo "" > /sys/kernel/debug/tracing/kprobe_events done } loop2 (){ while true do tree /sys/kernel/debug/tracing/events/kprobes/ done } loop1 & loop2 [1]: [ 1147.959632][T17331] Unable to handle kernel paging request at virtual address dead000000000150 [ 1147.968239][T17331] Mem abort info: [ 1147.971739][T17331] ESR = 0x0000000096000004 [ 1147.976172][T17331] EC = 0x25: DABT (current EL), IL = 32 bits [ 1147.982171][T17331] SET = 0, FnV = 0 [ 1147.985906][T17331] EA = 0, S1PTW = 0 [ 1147.989734][T17331] FSC = 0x04: level 0 translation fault [ 1147.995292][T17331] Data abort info: [ 1147.998858][T17331] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1148.005023][T17331] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1148.010759][T17331] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1148.016752][T17331] [dead000000000150] address between user and kernel address ranges [ 1148.024571][T17331] Internal error: Oops: 0000000096000004 [#1] SMP [ 1148.030825][T17331] Modules linked in: team_mode_loadbalance team nlmon act_gact cls_flower sch_ingress bonding tls macvlan dummy ib_core bridge stp llc veth amdgpu amdxcp mfd_core gpu_sched drm_exec drm_buddy radeon crct10dif_ce video drm_suballoc_helper ghash_ce drm_ttm_helper sha2_ce ttm sha256_arm64 i2c_algo_bit sha1_ce sbsa_gwdt cp210x drm_display_helper cec sr_mod cdrom drm_kms_helper binfmt_misc sg loop fuse drm dm_mod nfnetlink ip_tables autofs4 [last unloaded: tls] [ 1148.072808][T17331] CPU: 3 PID: 17331 Comm: ls Tainted: G W ------- ---- 6.6.43 #2 [ 1148.081751][T17331] Source Version: 21b3b386e948bedd29369af66f3e98ab01b1c650 [ 1148.088783][T17331] Hardware name: Greatwall GW-001M1A-FTF/GW-001M1A-FTF, BIOS KunLun BIOS V4.0 07/16/2020 [ 1148.098419][T17331] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1148.106060][T17331] pc : eventfs_iterate+0x2c0/0x398 [ 1148.111017][T17331] lr : eventfs_iterate+0x2fc/0x398 [ 1148.115969][T17331] sp : ffff80008d56bbd0 [ 1148.119964][T17331] x29: ffff80008d56bbf0 x28: ffff001ff5be2600 x27: 0000000000000000 [ 1148.127781][T17331] x26: ffff001ff52ca4e0 x25: 0000000000009977 x24: dead000000000100 [ 1148.135598][T17331] x23: 0000000000000000 x22: 000000000000000b x21: ffff800082645f10 [ 1148.143415][T17331] x20: ffff001fddf87c70 x19: ffff80008d56bc90 x18: 0000000000000000 [ 1148.151231][T17331] x17: 0000000000000000 x16: 0000000000000000 x15: ffff001ff52ca4e0 [ 1148.159048][T17331] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 1148.166864][T17331] x11: 0000000000000000 x10: 0000000000000000 x9 : ffff8000804391d0 [ 1148.174680][T17331] x8 : 0000000180000000 x7 : 0000000000000018 x6 : 0000aaab04b92862 [ 1148.182498][T17331] x5 : 0000aaab04b92862 x4 : 0000000080000000 x3 : 0000000000000068 [ 1148.190314][T17331] x2 : 000000000000000f x1 : 0000000000007ea8 x0 : 0000000000000001 [ 1148.198131][T17331] Call trace: [ 1148.201259][T17331] eventfs_iterate+0x2c0/0x398 [ 1148.205864][T17331] iterate_dir+0x98/0x188 [ 1148.210036][T17331] __arm64_sys_getdents64+0x78/0x160 [ 1148.215161][T17331] invoke_syscall+0x78/0x108 [ 1148.219593][T17331] el0_svc_common.constprop.0+0x48/0xf0 [ 1148.224977][T17331] do_el0_svc+0x24/0x38 [ 1148.228974][T17331] el0_svc+0x40/0x168 [ 1148.232798][T17331] el0t_64_sync_handler+0x120/0x130 [ 1148.237836][T17331] el0t_64_sync+0x1a4/0x1a8 [ 1148.242182][T17331] Code: 54ffff6c f9400676 910006d6 f9000676 (b9405300) [ 1148.248955][T17331] ---[ end trace 0000000000000000 ]--- The issue is that list_del() is used on an SRCU protected list variable before the synchronization occurs. This can poison the list pointers while there is a reader iterating the list. This is simply fixed by using list_del_rcu() that is specifically made for this purpose. Link: https://lore.kernel.org/linux-trace-kernel/20240829085025.3600021-1-chizhiling@163.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20240904131605.640d42b1@gandalf.local.home Fixes: 43aa6f97c2d03 ("eventfs: Get rid of dentry pointers without refcounts") Reported-by: Chi Zhiling <chizhiling@kylinos.cn> Tested-by: Chi Zhiling <chizhiling@kylinos.cn> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-09-05tracing: Avoid possible softlockup in tracing_iter_reset()Zheng Yejian
In __tracing_open(), when max latency tracers took place on the cpu, the time start of its buffer would be updated, then event entries with timestamps being earlier than start of the buffer would be skipped (see tracing_iter_reset()). Softlockup will occur if the kernel is non-preemptible and too many entries were skipped in the loop that reset every cpu buffer, so add cond_resched() to avoid it. Cc: stable@vger.kernel.org Fixes: 2f26ebd549b9a ("tracing: use timestamp to determine start of latency traces") Link: https://lore.kernel.org/20240827124654.3817443-1-zhengyejian@huaweicloud.com Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2024-09-05Merge tag 'samsung-soc-6.12' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/arm Samsung mach/soc changes for v6.12 1. Few ARM32 machine code cleanups, 2. Add dedicated maintainer entry for ARM64 Exynos850 DTS and driver code. * tag 'samsung-soc-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: ARM: s3c: remove unused s3c2410_cpu_suspend() declaration ARM: s3c: remove unused declarations for s3c6400 ARM: s3c: Remove unused s3c_init_uart_irqs() declaration MAINTAINERS: Add entry for Samsung Exynos850 SoC ARM: s3c: Drop explicit initialization of struct i2c_device_id::driver_data to 0 Link: https://lore.kernel.org/r/20240827121638.29707-3-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
generated by cgit (git 2.34.1) at 2025-09-23 03:00:28 +0000