aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10ata: pata_parport: add custom version of wait_after_resetOndrej Zary1-1/+67
Some parallel adapters (e.g. EXP Computer MC-1285B EPP Cable) return bogus values when there's no master device present. This can cause reset to fail, preventing the lone slave device (such as EXP Computer CD-865) from working. Add custom version of wait_after_reset that ignores master failure when a slave device is present. The custom version is also needed because the generic ata_sff_wait_after_reset uses direct port I/O for slave device detection. Signed-off-by: Ondrej Zary <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Damien Le Moal <[email protected]>
2023-10-10ata: pata_parport: implement set_devctlOndrej Zary1-0/+8
Add missing ops->sff_set_devctl implementation. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: [email protected] Signed-off-by: Ondrej Zary <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Damien Le Moal <[email protected]>
2023-10-10ata: pata_parport: fix pata_parport_devchkOndrej Zary1-1/+1
There's a 'x' missing in 0x55 in pata_parport_devchk(), causing the detection to always fail. Fix it. Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)") Cc: [email protected] Signed-off-by: Ondrej Zary <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Damien Le Moal <[email protected]>
2023-10-10hv/hv_kvp_daemon:Support for keyfile based connection profileShradha Gupta2-37/+235
Ifcfg config file support in NetworkManger is deprecated. This patch provides support for the new keyfile config format for connection profiles in NetworkManager. The patch modifies the hv_kvp_daemon code to generate the new network configuration in keyfile format(.ini-style format) along with a ifcfg format configuration. The ifcfg format configuration is also retained to support easy backward compatibility for distro vendors. These configurations are stored in temp files which are further translated using the hv_set_ifconfig.sh script. This script is implemented by individual distros based on the network management commands supported. For example, RHEL's implementation could be found here: https://gitlab.com/redhat/centos-stream/src/hyperv-daemons/-/blob/c9s/hv_set_ifconfig.sh Debian's implementation could be found here: https://github.com/endlessm/linux/blob/master/debian/cloud-tools/hv_set_ifconfig The next part of this support is to let the Distro vendors consume these modified implementations to the new configuration format. Tested-on: Rhel9(Hyper-V, Azure)(nm and ifcfg files verified) Signed-off-by: Shradha Gupta <[email protected]> Reviewed-by: Saurabh Sengar <[email protected]> Reviewed-by: Ani Sinha <[email protected]> Signed-off-by: Wei Liu <[email protected]> Link: https://lore.kernel.org/r/1696847920-31125-1-git-send-email-shradhagupta@linux.microsoft.com
2023-10-09net: refine debug info in skb_checksum_help()Eric Dumazet1-2/+6
syzbot uses panic_on_warn. This means that the skb_dump() I added in the blamed commit are not even called. Rewrite this so that we get the needed skb dump before syzbot crashes. Fixes: eeee4b77dc52 ("net: add more debug info in skb_checksum_help()") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Willem de Bruijn <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-09scsi: ufs: core: Correct clear TM error logPeter Wang1-1/+1
The clear TM function error log status was inverted. Fixes: 4693fad7d6d4 ("scsi: ufs: core: Log error handler activity") Signed-off-by: Peter Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-10-09drm/amdgpu: fix SI failure due to doorbells allocationIcenowy Zheng1-0/+4
SI hardware does not have doorbells at all, however currently the code will try to do the allocation and thus fail, makes SI AMDGPU not usable. Fix this failure by skipping doorbells allocation when doorbells count is zero. Fixes: 54c30d2a8def ("drm/amdgpu: create kernel doorbell pages") Reviewed-by: Shashank Sharma <[email protected]> Signed-off-by: Icenowy Zheng <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-09drm/amdgpu: add missing NULL checkChristian König1-1/+1
bo->tbo.resource can easily be NULL here. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2902 Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> CC: [email protected]
2023-10-09drm/amd/display: Don't set dpms_off for seamless bootDaniel Miess1-0/+3
[Why] eDPs fail to light up with seamless boot enabled [How] When seamless boot is enabled don't configure dpms_off in disable_vbios_mode_if_required. Reviewed-by: Charlene Liu <[email protected]> Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Tom Chung <[email protected]> Signed-off-by: Daniel Miess <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-10-10Merge branch 'icc-rpm-dt-bindings' into icc-nextGeorgi Djakov6-294/+352
The recent necessary overhaul [1] of how we represent SMD ICC and RPM bus clocks changed the way they're connected. The bindings however were not updated to reflect that. This series tries to address that, while also making the relevant bindings less convoluted. Now, instead of referencing RPM SMD bus clocks via clocks=<>, they're handled internally within the interconnect framework (via direct RPM calls from there). We still need to allow some "interface" clocks, which are necessary to access some registers and not managed for us. [1] https://lore.kernel.org/linux-arm-msm/[email protected]/ * icc-rpm-dt-bindings dt-bindings: interconnect: qcom: Introduce qcom,rpm-common dt-bindings: interconnect: qcom: qcm2290: Remove RPM bus clocks dt-bindings: interconnect: qcom: Fix and separate out SDM660 dt-bindings: interconnect: qcom: Fix and separate out MSM8996 dt-bindings: interconnect: qcom: Fix and separate out MSM8939 dt-bindings: interconnect: qcom: rpm: Clean up the file dt-bindings: interconnect: qcom: rpm: Clean up the example Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: rpm: Clean up the exampleKonrad Dybcio1-15/+3
One example is enough, remove the others and fix up the indentation while at it. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: rpm: Clean up the fileKonrad Dybcio1-57/+5
Following the recent cleanups and untanglements, remove abusive direct references to RPM bus clocks, include the rpm-common YAML and update Georgi's email. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: Fix and separate out MSM8939Konrad Dybcio2-49/+74
Separate out MSM8939 icc bindings from the common file and fix the clocks description by removing the wrong internal RPM bus clock representation that we've been carrying for years. This was the final one, so also retire the shared file. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: Fix and separate out MSM8996Konrad Dybcio2-81/+126
Separate out MSM8996 icc bindings from the common file and fix the clocks description by removing the wrong internal RPM bus clock representation that we've been carrying for years. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: Fix and separate out SDM660Konrad Dybcio2-40/+108
Separate out SDM660 icc bindings from the common file and fix the clocks description by removing the wrong internal RPM bus clock representation that we've been carrying for years. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: qcm2290: Remove RPM bus clocksKonrad Dybcio1-42/+0
After the recent reshuffling, bus clocks are no longer exposed as RPM clocks. Remove the old description. Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10dt-bindings: interconnect: qcom: Introduce qcom,rpm-commonKonrad Dybcio2-10/+36
The current RPM interconnect bindings are messy. Start cleaning them up with a common include. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-10Merge branch 'icc-qcom-coefficients' into icc-nextGeorgi Djakov6-15/+103
Certain platforms require that some buses (or individual nodes) make some additional changes to the clock rate formula, throwing in some magic, Qualcomm-defined coefficients, to account for "inefficiencies". Add the framework for it and utilize it on a couple SoCs. * icc-qcom-coefficients interconnect: qcom: icc-rpm: Add AB/IB calculations coefficients interconnect: qcom: icc-rpm: Separate out clock rate calulcations interconnect: qcom: icc-rpm: Let nodes drive their own bus clock interconnect: qcom: icc-rpm: Check for node-specific rate coefficients interconnect: qcom: qcm2290: Hook up MAS_APPS_PROC's bus clock interconnecga qcom: qcm2290: Set AB coefficients interconnecgg acom: qcm2290: Update EBI channel configuration interconnect: qcom: sdm660: Set AB/IB coefficients interconnect: qcom: msm8996: Set AB/IB coefficients Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09selftests/bpf: Add testcase for async callback return value failureDavid Vernet2-2/+51
A previous commit updated the verifier to print an accurate failure message for when someone specifies a nonzero return value from an async callback. This adds a testcase for validating that the verifier emits the correct message in such a case. Signed-off-by: David Vernet <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-10-09bpf: Fix verifier log for async callback return valuesDavid Vernet1-3/+3
The verifier, as part of check_return_code(), verifies that async callbacks such as from e.g. timers, will return 0. It does this by correctly checking that R0->var_off is in tnum_const(0), which effectively checks that it's in a range of 0. If this condition fails, however, it prints an error message which says that the value should have been in (0x0; 0x1). This results in possibly confusing output such as the following in which an async callback returns 1: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1) The fix is easy -- we should just pass the tnum_const(0) as the correct range to verbose_invalid_scalar(), which will then print the following: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0) Fixes: bfc6bb74e4f1 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by: David Vernet <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-10-09drm/vmwgfx: Keep a gem reference to user bos in surfacesZack Rusin11-49/+68
Surfaces can be backed (i.e. stored in) memory objects (mob's) which are created and managed by the userspace as GEM buffers. Surfaces grab only a ttm reference which means that the gem object can be deleted underneath us, especially in cases where prime buffer export is used. Make sure that all userspace surfaces which are backed by gem objects hold a gem reference to make sure they're not deleted before vmw surfaces are done with them, which fixes: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 2632 at lib/refcount.c:28 refcount_warn_saturate+0xfb/0x150 Modules linked in: overlay vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock snd_ens1371 snd_ac97_codec ac97_bus snd_pcm gameport> CPU: 2 PID: 2632 Comm: vmw_ref_count Not tainted 6.5.0-rc2-vmwgfx #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:refcount_warn_saturate+0xfb/0x150 Code: eb 9e 0f b6 1d 8b 5b a6 01 80 fb 01 0f 87 ba e4 80 00 83 e3 01 75 89 48 c7 c7 c0 3c f9 a3 c6 05 6f 5b a6 01 01 e8 15 81 98 ff <0f> 0b e9 6f ff ff ff 0f b> RSP: 0018:ffffbdc34344bba0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff960475ea1548 RSI: 0000000000000001 RDI: ffff960475ea1540 RBP: ffffbdc34344bba8 R08: 0000000000000003 R09: 65646e75203a745f R10: ffffffffa5b32b20 R11: 72657466612d6573 R12: ffff96037d6a6400 R13: ffff9603484805b0 R14: 000000000000000b R15: ffff9603bed06060 FS: 00007f5fd8520c40(0000) GS:ffff960475e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5fda755000 CR3: 000000010d012005 CR4: 00000000003706e0 Call Trace: <TASK> ? show_regs+0x6e/0x80 ? refcount_warn_saturate+0xfb/0x150 ? __warn+0x91/0x150 ? refcount_warn_saturate+0xfb/0x150 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xfb/0x150 drm_gem_object_handle_put_unlocked+0xba/0x110 [drm] drm_gem_object_release_handle+0x6e/0x80 [drm] drm_gem_handle_delete+0x6a/0xc0 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] vmw_bo_unref_ioctl+0x33/0x40 [vmwgfx] drm_ioctl_kernel+0xbc/0x160 [drm] drm_ioctl+0x2d2/0x580 [drm] ? __pfx_vmw_bo_unref_ioctl+0x10/0x10 [vmwgfx] ? do_vmi_munmap+0xee/0x180 vmw_generic_ioctl+0xbd/0x180 [vmwgfx] vmw_unlocked_ioctl+0x19/0x20 [vmwgfx] __x64_sys_ioctl+0x99/0xd0 do_syscall_64+0x5d/0x90 ? syscall_exit_to_user_mode+0x2a/0x50 ? do_syscall_64+0x6d/0x90 ? handle_mm_fault+0x16e/0x2f0 ? exit_to_user_mode_prepare+0x34/0x170 ? irqentry_exit_to_user_mode+0xd/0x20 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x8e/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f5fda51aaff Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 7> RSP: 002b:00007ffd536a4d30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffd536a4de0 RCX: 00007f5fda51aaff RDX: 00007ffd536a4de0 RSI: 0000000040086442 RDI: 0000000000000003 RBP: 0000000040086442 R08: 000055fa603ada50 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffd536a51b8 R13: 0000000000000003 R14: 000055fa5ebb4c80 R15: 00007f5fda90f040 </TASK> ---[ end trace 0000000000000000 ]--- A lot of the analyis on the bug was done by Murray McAllister and Ian Forbes. Reported-by: Murray McAllister <[email protected]> Cc: Ian Forbes <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Fixes: a950b989ea29 ("drm/vmwgfx: Do not drop the reference to the handle too soon") Cc: <[email protected]> # v6.2+ Reviewed-by: Martin Krastev <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-09drm/vmwgfx: fix typo of sizeof argumentKonstantin Meskhidze1-1/+1
Since size of 'header' pointer and '*header' structure is equal on 64-bit machines issue probably didn't cause any wrong behavior. But anyway, fixing typo is required. Fixes: 7a73ba7469cb ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Co-developed-by: Ivanov Mikhail <[email protected]> Signed-off-by: Konstantin Meskhidze <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-09cgroup: Remove duplicates in cgroup v1 tasks fileMichal Koutný1-3/+2
One PID may appear multiple times in a preloaded pidlist. (Possibly due to PID recycling but we have reports of the same task_struct appearing with different PIDs, thus possibly involving transfer of PID via de_thread().) Because v1 seq_file iterator uses PIDs as position, it leads to a message: > seq_file: buggy .next function kernfs_seq_next did not update position index Conservative and quick fix consists of removing duplicates from `tasks` file (as opposed to removing pidlists altogether). It doesn't affect correctness (it's sufficient to show a PID once), performance impact would be hidden by unconditional sorting of the pidlist already in place (asymptotically). Link: https://lore.kernel.org/r/[email protected]/ Suggested-by: Firo Yang <[email protected]> Signed-off-by: Michal Koutný <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected]
2023-10-09xdp: Fix zero-size allocation warning in xskq_create()Andrew Kanner1-0/+10
Syzkaller reported the following issue: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 2807 at mm/vmalloc.c:3247 __vmalloc_node_range (mm/vmalloc.c:3361) Modules linked in: CPU: 0 PID: 2807 Comm: repro Not tainted 6.6.0-rc2+ #12 Hardware name: Generic DT based system unwind_backtrace from show_stack (arch/arm/kernel/traps.c:258) show_stack from dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) dump_stack_lvl from __warn (kernel/panic.c:633 kernel/panic.c:680) __warn from warn_slowpath_fmt (./include/linux/context_tracking.h:153 kernel/panic.c:700) warn_slowpath_fmt from __vmalloc_node_range (mm/vmalloc.c:3361 (discriminator 3)) __vmalloc_node_range from vmalloc_user (mm/vmalloc.c:3478) vmalloc_user from xskq_create (net/xdp/xsk_queue.c:40) xskq_create from xsk_setsockopt (net/xdp/xsk.c:953 net/xdp/xsk.c:1286) xsk_setsockopt from __sys_setsockopt (net/socket.c:2308) __sys_setsockopt from ret_fast_syscall (arch/arm/kernel/entry-common.S:68) xskq_get_ring_size() uses struct_size() macro to safely calculate the size of struct xsk_queue and q->nentries of desc members. But the syzkaller repro was able to set q->nentries with the value initially taken from copy_from_sockptr() high enough to return SIZE_MAX by struct_size(). The next PAGE_ALIGN(size) is such case will overflow the size_t value and set it to 0. This will trigger WARN_ON_ONCE in vmalloc_user() -> __vmalloc_node_range(). The issue is reproducible on 32-bit arm kernel. Fixes: 9f78bf330a66 ("xsk: support use vaddr as ring") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/T/ Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/T/ Signed-off-by: Andrew Kanner <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: [email protected] Acked-by: Magnus Karlsson <[email protected]> Link: https://syzkaller.appspot.com/bug?extid=fae676d3cf469331fc89 Link: https://lore.kernel.org/bpf/[email protected]
2023-10-09Merge tag 'irqchip-fixes-6.6-2' of ↵Thomas Gleixner10-123/+329
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zyngier: - DT binding updates for Renesas r8a779f0 and rzg2l - Let GICv3 honor the "dma-non-coherent" attribute for systems that rely on SW guessing what the HW supports - Fix the RISC-V INTC probing by marking all devices as initialised at once - Properly translate interrupt numbers from DT on stm32-exti - Use irq_data_get_irq_chip_data() in the rzg2l driver instead of blindly dereferencing the irq_data structure - Add a MAINTAINERS entry for the various ARM GIC irqchip drivers - Remove myself as the top-level irqchip/irqdomain maintainer Link: https://lore.kernel.org/all/[email protected]
2023-10-09riscv, bpf: Track both a0 (RISC-V ABI) and a5 (BPF) return valuesBjörn Töpel1-4/+9
The RISC-V BPF uses a5 for BPF return values, which are zero-extended, whereas the RISC-V ABI uses a0 which is sign-extended. In other words, a5 and a0 can differ, and are used in different context. The BPF trampoline are used for both BPF programs, and regular kernel functions. Make sure that the RISC-V BPF trampoline saves, and restores both a0 and a5. Fixes: 49b5e77ae3e2 ("riscv, bpf: Add bpf trampoline support for RV64") Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2023-10-09riscv, bpf: Sign-extend return valuesBjörn Töpel1-2/+3
The RISC-V architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format [1] [2]: | The compiler and calling convention maintain an invariant that all | 32-bit values are held in a sign-extended format in 64-bit | registers. Even 32-bit unsigned integers extend bit 31 into bits | 63 through 32. Consequently, conversion between unsigned and | signed 32-bit integers is a no-op, as is conversion from a signed | 32-bit integer to a signed 64-bit integer. While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86). This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in RISC-V land), passed the return value up the kernel, e.g.: | int from_bpf(void); | | long foo(void) | { | return from_bpf(); | } Here, a0 would be 0xffff_ffff, instead of the expected 0xffff_ffff_ffff_ffff. Internally, the RISC-V JIT uses a5 as a dedicated register for BPF return values. Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs, a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL). Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2] Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2] Link: https://lore.kernel.org/bpf/[email protected]
2023-10-09ACPI: resource: Add TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q to ↵Hans de Goede1-6/+13
irq1_edge_low_force_override[] The TongFang GM6BGEQ, GM6BG5Q and GM6BG0Q are 3 GPU variants of a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. Adjust the pcspecialist_laptop[] DMI match table for this: 1. Drop the sys-vendor match from the existing PCSpecialist Elimina Pro 16 entry for the GM6BGEQ (RTX3050 GPU) model so that it will also match the laptop when sold by other vendors such as hyperbook.pl. 2. Add board-name matches for the GM6BG5Q (RTX4050) and GM6B0Q (RTX4060) models. Note the .ident values of the dmi_system_id structs are left unset since these are not used. Suggested-by: August Wikerfors <[email protected]> Reported-by: Francesco <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217394 Link: https://laptopparts4less.frl/index.php?route=product/search&filter_name=GM6BG Link: https://hyperbook.pl/en/content/14-hyperbook-drivers Link: https://linux-hardware.org/?probe=bfa70344e3 Link: https://bbs.archlinuxcn.org/viewtopic.php?id=13313 Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2023-10-09interconnect: qcom: msm8996: Set AB/IB coefficientsKonrad Dybcio1-2/+6
Some buses and nodes need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: sdm660: Set AB/IB coefficientsKonrad Dybcio1-0/+4
Some buses and nodes need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Update EBI channel configurationKonrad Dybcio1-1/+2
QCM2290 can support two memory configurations: single-channel, 32-bit wide LPDDR3 @ up to 933MHz (bus clock) or dual-channel, 16-bit wide LPDDR4X @ up to 1804 MHz. The interconnect driver in its current form seems to gravitate towards the first one, however there are no LPDDR3- equipped boards upstream and we still don't have a great way to discern the DDR generations on the kernel side. To make DDR scaling possible on the only currently-supported 2290 board, stick with the LPDDR4X config by default. The side effect on any potential LPDDR3 board would be that the requested bus clock rate is too high (but still capped to the firmware-configured FMAX). Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Set AB coefficientsKonrad Dybcio1-0/+3
Some buses need additional manual adjustments atop the usual calculations. Fill in the missing coefficients. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: qcm2290: Hook up MAS_APPS_PROC's bus clockKonrad Dybcio3-0/+10
This single node has its own clock which seems to be responsible for transactions between CPUSS (CPU + some stuff) and the GNOC. See [1] for reference. Define it and hook it up. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/02f8c342b23c20a5cf967df649814be37a08227c%5E%21/#F0 Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Check for node-specific rate coefficientsKonrad Dybcio2-4/+14
Some nodes may have different coefficients than the general values for bus they're attached to. Check for that and use them if present. See [1], [2] for reference. [1] https://github.com/sonyxperiadev/kernel/commit/7456d9779af9ad6bb9c7ee6f33d5c5a8d3648e24 [2] https://github.com/artem/android_kernel_sony_msm8996/commit/bf7a8985dcaf0eab5bc2562d2d6775e7e29c0f30 Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Let nodes drive their own bus clockKonrad Dybcio2-0/+31
If this hardware couldn't get messier, some nodes are supposed to drive their own bus clock.. Presumably to connect to some intermediate interface between the node itself and the bus it's (supposed to be) connected to. Expand the node struct with the necessary data and hook up the allocations & calculations. Note that the node-specific AB/IB coefficients contribute (by design) to both the node-level and the bus-level aggregation. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Separate out clock rate calulcationsKonrad Dybcio1-23/+30
In preparation for also setting per-node clock rates, separate out the logic that computes it. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09interconnect: qcom: icc-rpm: Add AB/IB calculations coefficientsKonrad Dybcio2-3/+21
Presumably due to the hardware being so complex, some nodes (or busses) have different (usually higher) requirements for bandwidth than what the usual calculations would suggest. Looking at the available downstream files, it seems like AB values are adjusted per-bus and IB values are adjusted per-node. With that in mind, introduce percentage-based coefficient struct members and use them in the calculations. One thing to note is that the IB coefficient is inverse (100/ib_percent) which feels a bit backwards, but it's necessary for precision.. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-10-09powerpc/64e: Fix wrong test in __ptep_test_and_clear_young()Christophe Leroy1-1/+1
Commit 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.") replaced: if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0) return 0; By: if (pte_young(*ptep)) return 0; But it should be: if (!pte_young(*ptep)) return 0; Fix it. Fixes: 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/8bb7f06494e21adada724ede47a4c3d97e879d40.1695659959.git.christophe.leroy@csgroup.eu
2023-10-09powerpc/8xx: Fix pte_access_permitted() for PAGE_NONEChristophe Leroy2-0/+9
On 8xx, PAGE_NONE is handled by setting _PAGE_NA instead of clearing _PAGE_USER. But then pte_user() returns 1 also for PAGE_NONE. As _PAGE_NA prevent reads, add a specific version of pte_read() that returns 0 when _PAGE_NA is set instead of always returning 1. Fixes: 351750331fc1 ("powerpc/mm: Introduce _PAGE_NA") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/57bcfbe578e43123f9ed73e040229b80f1ad56ec.1695659959.git.christophe.leroy@csgroup.eu
2023-10-09ceph: fix type promotion bug on 32bit systemsDan Carpenter1-1/+1
In this code "ret" is type long and "src_objlen" is unsigned int. The problem is that on 32bit systems, when we do the comparison signed longs are type promoted to unsigned int. So negative error codes from do_splice_direct() are treated as success instead of failure. Cc: [email protected] Fixes: 1b0c3b9f91f0 ("ceph: re-org copy_file_range and fix some error paths") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Xiubo Li <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2023-10-09libceph: use kernel_connect()Jordan Rife1-2/+2
Direct calls to ops->connect() can overwrite the address parameter when used in conjunction with BPF SOCK_ADDR hooks. Recent changes to kernel_connect() ensure that callers are insulated from such side effects. This patch wraps the direct call to ops->connect() with kernel_connect() to prevent unexpected changes to the address passed to ceph_tcp_connect(). This change was originally part of a larger patch targeting the net tree addressing all instances of unprotected calls to ops->connect() throughout the kernel, but this change was split up into several patches targeting various trees. Cc: [email protected] Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect") Signed-off-by: Jordan Rife <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2023-10-09ceph: remove unnecessary IS_ERR() check in ceph_fname_to_usr()Luis Henriques1-1/+1
Before returning, function ceph_fname_to_usr() does a final IS_ERR() check in 'dir': if ((dir != fname->dir) && !IS_ERR(dir)) {...} This check is unnecessary because, if the 'dir' variable has changed to something other than 'fname->dir' (it's initial value), that error check has been performed already and, if there was indeed an error, it would have been returned immediately. Besides, this useless IS_ERR() is also confusing static analysis tools. Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Luis Henriques <[email protected]> Reviewed-by: Ilya Dryomov <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2023-10-09ceph: fix incorrect revoked caps assert in ceph_fill_file_size()Xiubo Li1-3/+1
When truncating the inode the MDS will acquire the xlock for the ifile Locker, which will revoke the 'Frwsxl' caps from the clients. But when the client just releases and flushes the 'Fw' caps to MDS, for exmaple, and once the MDS receives the caps flushing msg it just thought the revocation has finished. Then the MDS will continue truncating the inode and then issued the truncate notification to all the clients. While just before the clients receives the cap flushing ack they receive the truncation notification, the clients will detecte that the 'issued | dirty' is still holding the 'Fw' caps. Cc: [email protected] Link: https://tracker.ceph.com/issues/56693 Fixes: b0d7c2231015 ("ceph: introduce i_truncate_mutex") Signed-off-by: Xiubo Li <[email protected]> Reviewed-by: Milind Changire <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2023-10-09printk: flush consoles before checking progressJohn Ogness1-1/+7
Commit 9e70a5e109a4 ("printk: Add per-console suspended state") removed console lock usage during resume and replaced it with the clearly defined console_list_lock and srcu mechanisms. However, the console lock usage had an important side-effect of flushing the consoles. After its removal, consoles were no longer flushed before checking their progress. Add the console_lock/console_unlock dance to the beginning of __pr_flush() to actually flush the consoles before checking their progress. Also add comments to clarify this additional usage of the console lock. Note that console_unlock() does not guarantee flushing all messages since the commit dbdda842fe96f89 ("printk: Add console owner and waiter logic to load balance console writes"). Reported-by: Todd Brandt <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217955 Fixes: 9e70a5e109a4 ("printk: Add per-console suspended state") Co-developed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Signed-off-by: John Ogness <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-09sched/eevdf: Fix pick_eevdf()Benjamin Segall1-14/+58
The old pick_eevdf() could fail to find the actual earliest eligible deadline when it descended to the right looking for min_deadline, but it turned out that that min_deadline wasn't actually eligible. In that case we need to go back and search through any left branches we skipped looking for the actual best _eligible_ min_deadline. This is more expensive, but still O(log n), and at worst should only involve descending two branches of the rbtree. I've run this through a userspace stress test (thank you tools/lib/rbtree.c), so hopefully this implementation doesn't miss any corner cases. Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") Signed-off-by: Ben Segall <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2023-10-09sched/eevdf: Fix min_deadline heap integrityPeter Zijlstra1-0/+1
Marek and Biju reported instances of: "EEVDF scheduling fail, picking leftmost" which Mike correlated with cgroup scheduling and the min_deadline heap getting corrupted; some trace output confirms: > And yeah, min_deadline is hosed somehow: > > validate_cfs_rq: --- / > __print_se: ffff88845cf48080 w: 1024 ve: -58857638 lag: 870381 vd: -55861854 vmd: -66302085 E (11372/tr) > __print_se: ffff88810d165800 w: 25 ve: -80323686 lag: 22336429 vd: -41496434 vmd: -66302085 E (-1//autogroup-31) > __print_se: ffff888108379000 w: 25 ve: 0 lag: -57987257 vd: 114632828 vmd: 114632828 N (-1//autogroup-33) > validate_cfs_rq: min_deadline: -55861854 avg_vruntime: -62278313462 / 1074 = -57987256 Turns out that reweight_entity(), which tries really hard to be fast, does not do the normal dequeue+update+enqueue pattern but *does* scale the deadline. However, it then fails to propagate the updated deadline value up the heap. Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") Reported-by: Marek Szyprowski <[email protected]> Reported-by: Biju Das <[email protected]> Reported-by: Mike Galbraith <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Tested-by: Biju Das <[email protected]> Tested-by: Mike Galbraith <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2023-10-09xen/events: replace evtchn_rwlock with RCUJuergen Gross1-41/+46
In unprivileged Xen guests event handling can cause a deadlock with Xen console handling. The evtchn_rwlock and the hvc_lock are taken in opposite sequence in __hvc_poll() and in Xen console IRQ handling. Normally this is no problem, as the evtchn_rwlock is taken as a reader in both paths, but as soon as an event channel is being closed, the lock will be taken as a writer, which will cause read_lock() to block: CPU0 CPU1 CPU2 (IRQ handling) (__hvc_poll()) (closing event channel) read_lock(evtchn_rwlock) spin_lock(hvc_lock) write_lock(evtchn_rwlock) [blocks] spin_lock(hvc_lock) [blocks] read_lock(evtchn_rwlock) [blocks due to writer waiting, and not in_interrupt()] This issue can be avoided by replacing evtchn_rwlock with RCU in xen_free_irq(). Note that RCU is used only to delay freeing of the irq_info memory. There is no RCU based dereferencing or replacement of pointers involved. In order to avoid potential races between removing the irq_info reference and handling of interrupts, set the irq_info pointer to NULL only when freeing its memory. The IRQ itself must be freed at that time, too, as otherwise the same IRQ number could be allocated again before handling of the old instance would have been finished. This is XSA-441 / CVE-2023-34324. Fixes: 54c9de89895e ("xen/events: add a new "late EOI" evtchn framework") Reported-by: Marek Marczykowski-Górecki <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Julien Grall <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2023-10-09ALSA: usb-audio: Fix microphone sound on Nexigo webcam.Christos Skevis2-0/+9
I own an external usb Webcam, model NexiGo N930AF, which had low mic volume and inconsistent sound quality. Video works as expected. (snip) [ +0.047857] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.003406] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000007] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.003900] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) [ +0.025726] usb 5-1: 3:1: cannot get usb sound sample rate freq at ep 0x86 [ +0.071482] usb 5-1: 3:2: cannot get usb sound sample rate freq at ep 0x86 [ +0.004679] usb 5-1: 3:3: cannot get usb sound sample rate freq at ep 0x86 [ +0.051607] usb 5-1: Warning! Unlikely big volume range (=4096), cval->res is probably wrong. [ +0.000005] usb 5-1: [7] 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 : (snip) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 8 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] 44100 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x005c 1x 92 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) Based on the usb data about manufacturer, SPCA2281B3 is the most likely controller IC Manufacturer does not provide link for datasheet nor detailed specs. No way to confirm if the firmware supports any other way of getting the sample rate. Testing patch provides consistent good sound recording quality and volume range. (snip) [ +0.045764] usb 5-1: new high-speed USB device number 2 using xhci_hcd [ +0.106290] usb 5-1: New USB device found, idVendor=1bcf, idProduct=2283, bcdDevice=12.17 [ +0.000006] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ +0.000004] usb 5-1: Product: NexiGo N930AF FHD Webcam [ +0.000003] usb 5-1: Manufacturer: SHENZHEN AONI ELECTRONIC CO., LTD [ +0.000004] usb 5-1: SerialNumber: 20201217011 [ +0.043700] usb 5-1: set resolution quirk: cval->res = 16 [ +0.002585] usb 5-1: Found UVC 1.00 device NexiGo N930AF FHD Webcam (1bcf:2283) Signed-off-by: Christos Skevis <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2023-10-09dmaengine: fsl-edma: fix all channels requested when call fsl_edma3_xlate()Frank Li1-2/+4
dma_get_slave_channel() increases client_count for all channels. It should only be called when a matched channel is found in fsl_edma3_xlate(). Move dma_get_slave_channel() after checking for a matched channel. Cc: [email protected] Fixes: 72f5801a4e2b ("dmaengine: fsl-edma: integrate v3 support") Signed-off-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2023-10-09dmaengine: stm32-dma: fix residue in case of MDMA chainingAmelie Delaunay1-3/+4
In case of MDMA chaining, DMA is configured in Double-Buffer Mode (DBM) with two periods, but if transfer has been prepared with _prep_slave_sg(), the transfer is not marked cyclic (=!chan->desc->cyclic). However, as DBM is activated for MDMA chaining, residue computation must take into account cyclic constraints. With only two periods in MDMA chaining, and no update due to Transfer Complete interrupt masked, n_sg is always 0. If DMA current memory address (depending on SxCR.CT and SxM0AR/SxM1AR) does not correspond, it means n_sg should be increased. Then, the residue of the current period is the one read from SxNDTR and should not be overwritten with the full period length. Fixes: 723795173ce1 ("dmaengine: stm32-dma: add support to trigger STM32 MDMA") Signed-off-by: Amelie Delaunay <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.