aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-02-19parisc: Fix stack unwinderGuenter Roeck1-8/+6
Debugging shows a large number of unaligned access traps in the unwinder code. Code analysis reveals a number of issues with this code: - handle_interruption is passed twice through dereference_kernel_function_descriptor() - ret_from_kernel_thread, syscall_exit, intr_return, _switch_to_ret, and _call_on_stack are passed through dereference_kernel_function_descriptor() even though they are not declared as function pointers. To fix the problems, drop one of the calls to dereference_kernel_function_descriptor() for handle_interruption, and compare the other pointers directly. Fixes: 6414b30b39f9 ("parisc: unwind: Avoid missing prototype warning for handle_interruption()") Fixes: 8e0ba125c2bf ("parisc/unwind: fix unwinder when CONFIG_64BIT is enabled") Cc: Helge Deller <[email protected]> Cc: Sven Schnelle <[email protected]> Cc: John David Anglin <[email protected]> Cc: Charlie Jenkins <[email protected]> Cc: David Laight <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2024-02-19drm/ci: mark universal-plane-sanity as failing on SC7180Dmitry Baryshkov2-0/+2
The test kms_universal_plane@universal-plane-sanity fails on both SC7180 platforms. The drm/msm returns -ERANGE as it can not handle passet scaling range, however the test is not ready to handle that. Mark the test as failing until it is fixed. ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Test assertion failure function sanity_test_pipe, file ../tests/kms_universal_plane.c:438: ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Failed assertion: drmModeSetPlane(data->drm_fd, primary->drm_plane->plane_id, output->config.crtc->crtc_id, test.oversized_fb.fb_id, 0, 0, 0, mode->hdisplay + 100, mode->vdisplay + 100, IGT_FIXED(0,0), IGT_FIXED(0,0), IGT_FIXED(mode->hdisplay,0), IGT_FIXED(mode->vdisplay,0)) == expect ERROR - Igt error: (kms_universal_plane:1554) CRITICAL: Last errno: 34, Numerical result out of range Signed-off-by: Dmitry Baryshkov <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19drm/ci: update msm-apq8096-fails listDmitry Baryshkov1-2/+0
Mark two tests as passing on the APQ8096 / db820c platform. Signed-off-by: Dmitry Baryshkov <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19drm/ci: update IGT test namesDmitry Baryshkov1-1044/+844
Since the addition of testlist.txt the IGT has changed some of test names. Some test names were changed to use '-' instead of '_'. In other cases tests were just renamed. Follow those changes. Signed-off-by: Dmitry Baryshkov <[email protected]> Reported-by: Rob Clark <[email protected]> Acked-by: Helen Koike <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19drm/amdgpu: add MMHUB 3.3.1 supportYifan Zhang2-0/+2
This patch to add MMHUB 3.3.1 support. v2: squash in fault info fix (Alex) Signed-off-by: Yifan Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-19drm/amd/display: Remove break after returnRodrigo Siqueira1-1/+0
Remove break after return since it will never be reached. Tested-by: Daniel Wheeler <[email protected]> Reviewed-by: Hamza Mahfooz <[email protected]> Signed-off-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-19drm/ci: skip suspend tests for both msm-sc7180 machinesDmitry Baryshkov2-0/+4
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown") dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM tests. However testing shows that STR tests still can fail. Restore the skiplist, applying it to both limozeen and kingoftown machines. Fixes: ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown") Signed-off-by: Dmitry Baryshkov <[email protected]> Acked-by: Vignesh Raman <[email protected]> Signed-off-by: Helen Koike <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19PCI/MSI: Prevent MSI hardware interrupt number truncationVidya Sagar1-1/+1
While calculating the hardware interrupt number for a MSI interrupt, the higher bits (i.e. from bit-5 onwards a.k.a domain_nr >= 32) of the PCI domain number gets truncated because of the shifted value casting to return type of pci_domain_nr() which is 'int'. This for example is resulting in same hardware interrupt number for devices 0019:00:00.0 and 0039:00:00.0. To address this cast the PCI domain number to 'irq_hw_number_t' before left shifting it to calculate the hardware interrupt number. Please note that this fixes the issue only on 64-bit systems and doesn't change the behavior for 32-bit systems i.e. the 32-bit systems continue to have the issue. Since the issue surfaces only if there are too many PCIe controllers in the system which usually is the case in modern server systems and they don't tend to run 32-bit kernels. Fixes: 3878eaefb89a ("PCI/MSI: Enhance core to support hierarchy irqdomain") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Shanker Donthineni <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2024-02-19irqchip/sifive-plic: Enable interrupt if needed before EOINam Cao1-1/+7
RISC-V PLIC cannot "end-of-interrupt" (EOI) disabled interrupts, as explained in the description of Interrupt Completion in the PLIC spec: "The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that *is currently enabled* for the target, the completion is silently ignored." Commit 69ea463021be ("irqchip/sifive-plic: Fixup EOI failed when masked") ensured that EOI is successful by enabling interrupt first, before EOI. Commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations") removed the interrupt enabling code from the previous commit, because it assumes that interrupt should already be enabled at the point of EOI. However, this is incorrect: there is a window after a hart claiming an interrupt and before irq_desc->lock getting acquired, interrupt can be disabled during this window. Thus, EOI can be invoked while the interrupt is disabled, effectively nullify this EOI. This results in the interrupt never gets asserted again, and the device who uses this interrupt appears frozen. Make sure that interrupt is really enabled before EOI. Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations") Signed-off-by: Nam Cao <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Palmer Dabbelt <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Samuel Holland <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Guo Ren <[email protected]> Cc: [email protected] Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-02-19platform/x86/amd/pmf: Fix a potential race with policy binary sideloadMario Limonciello1-2/+3
The debugfs `update_policy` file is created before amd_pmf_start_policy_engine() has completed, and thus there could be a possible (albeit unlikely) race between sideloading a policy and the BIOS policy getting setup. Move the debugfs file creation after all BIOS policy is setup. Fixes: 10817f28e533 ("platform/x86/amd/pmf: Add capability to sideload of policy binary") Reported-by: Hans de Goede <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/T/#m2c445f135e5ef9b53184be7fc9df84e15f89d4d9 Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19platform/x86/amd/pmf: Fixup error handling for amd_pmf_init_smart_pc()Mario Limonciello1-25/+40
amd_pmf_init_smart_pc() calls out to amd_pmf_get_bios_buffer() but the error handling flow doesn't clean everything up allocated memory. As amd_pmf_get_bios_buffer() is only called by amd_pmf_init_smart_pc(), fold it into the function and add labels to clean up any step that can fail along the way. Explicitly set everything allocated to NULL as there are other features that may access some of the same variables. Fixes: 7c45534afa44 ("platform/x86/amd/pmf: Add support for PMF Policy Binary") Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19platform/x86/amd/pmf: Add debugging message for missing policy dataMario Limonciello1-1/+3
If a machine advertises Smart PC support but is missing policy data show a debugging message to help clarify why Smart PC wasn't enabled. Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2024-02-19platform/x86/amd/pmf: Fix a suspend hang on Framework 13Mario Limonciello1-2/+0
The buffer is cleared in the suspend handler but used in the delayed work for amd_pmf_get_metrics(). Stop clearing it to fix the hang. Reported-by: Trolli Schmittlauch <[email protected]> Closes: https://lore.kernel.org/regressions/ed2226ff-257b-4cfd-afd6-bf3be9785474@localhost/ Closes: https://community.frame.work/t/kernel-6-8-rc-system-freezes-after-resuming-from-suspend-reproducers-wanted/45381 Fixes: 2b3a7f06caaf ("platform/x86/amd/pmf: Change return type of amd_pmf_set_dram_addr()") Signed-off-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19platform/x86/amd/pmf: Fix TEE enact command failure after suspend and resumeShyam Sundar S K1-0/+6
TEE enact command failures are seen after each suspend/resume cycle; fix this by cancelling the policy builder workqueue before going into suspend and reschedule the workqueue after resume. [ 629.516792] ccp 0000:c2:00.2: tee: command 0x5 timed out, disabling PSP [ 629.516835] amd-pmf AMDI0102:00: TEE enact cmd failed. err: ffff000e, ret:0 [ 630.550464] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_RESPONSE:1 [ 630.550511] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_ARGUMENT:7 [ 630.550548] amd-pmf AMDI0102:00: AMD_PMF_REGISTER_MESSAGE:16 Fixes: ae82cef7d9c5 ("platform/x86/amd/pmf: Add support for PMF-TA interaction") Co-developed-by: Patil Rajesh Reddy <[email protected]> Signed-off-by: Patil Rajesh Reddy <[email protected]> Signed-off-by: Shyam Sundar S K <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19platform/x86/amd/pmf: Remove smart_pc_status enumShyam Sundar S K3-10/+10
Improve code readability by removing smart_pc_status enum, as the same can be done with a simple true/false check; Update the code checks accordingly. Also add a missing return on amd_pmf_init_smart_pc() success, to skip trying to setup the auto / slider modes which should not be used in this case. Signed-off-by: Shyam Sundar S K <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19drm/msm/mdp5: drop global_state_lockDmitry Baryshkov2-9/+0
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with private objects") the DRM framework no longer requires the external lock for private objects. Drop the lock, letting the DRM to manage private object locking. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570183/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/mdp5: migrate SMP dumping to using atomic_print_stateDmitry Baryshkov4-49/+15
The Shared Memory Pool (SMP) state is a part of the MDP5's private object state. Use existing infrastructure, atomic_print_state() callback, to dump SMP state (which also makes it included into debugfs/dri/N/state). This allows us to drop the custom debugfs file too. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570179/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/dpu: drop global_state_lockDmitry Baryshkov2-9/+0
Since the commit b962a12050a3 ("drm/atomic: integrate modeset lock with private objects") the DRM framework no longer requires the external lock for private objects. Drop the lock, letting the DRM to manage private object locking. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570174/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/dpu: finalise global state objectDmitry Baryshkov1-0/+8
Add calls to finalise global state object and corresponding lock. Fixes: de3916c70a24 ("drm/msm/dpu: Track resources in global state") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/570175/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/xe/uapi: Remove support for persistent exec_queuesThomas Hellström8-96/+6
Persistent exec_queues delays explicit destruction of exec_queues until they are done executing, but destruction on process exit is still immediate. It turns out no UMD is relying on this functionality, so remove it. If there turns out to be a use-case in the future, let's re-add. Persistent exec_queues were never used for LR VMs v2: - Don't add an "UNUSED" define for the missing property (Lucas, Rodrigo) v3: - Remove the remaining struct xe_exec_queue::persistent state (Niranjana, Lucas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <[email protected]> Cc: Matthew Brost <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Francois Dugast <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19platform/x86: touchscreen_dmi: Consolidate Goodix upside-down touchscreen dataHans de Goede1-15/+10
Now that prefix matches for ACPI names are supported, the ts_dmi_data structs for "GDIX1001:00" and "GDIX1001:01" can be consolidated into a single match matching on "GDIX1001". For consistency also change gdix1002_00_upside_down_data to match. Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-02-19platform/x86: touchscreen_dmi: Allow partial (prefix) matches for ACPI namesHans de Goede1-2/+2
On some devices the ACPI name of the touchscreen is e.g. either MSSL1680:00 or MSSL1680:01 depending on the BIOS version. This happens for example on the "Chuwi Hi8 Air" tablet where the initial commit's ts_data uses "MSSL1680:00" but the tablets from the github issue and linux-hardware.org probe linked below both use "MSSL1680:01". Replace the strcmp() match on ts_data->acpi_name with a strstarts() check to allow using a partial match on just the ACPI HID of "MSSL1680" and change the ts_data->acpi_name for the "Chuwi Hi8 Air" accordingly to fix the touchscreen not working on models where it is "MSSL1680:01". Note this drops the length check for I2C_NAME_SIZE. This never was necessary since the ACPI names used are never more then 11 chars and I2C_NAME_SIZE is 20 so the replaced strncmp() would always stop long before reaching I2C_NAME_SIZE. Link: https://linux-hardware.org/?computer=AC4301C0542A Fixes: bbb97d728f77 ("platform/x86: touchscreen_dmi: Add info for the Chuwi Hi8 Air tablet") Closes: https://github.com/onitake/gsl-firmware/issues/91 Cc: [email protected] Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-02-19platform/x86: intel: int0002_vgpio: Pass IRQF_ONESHOT to request_irq()Hans de Goede1-1/+1
Since commit 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") the ACPI OSL code passes IRQF_ONESHOT when requesting the SCI. Since the INT0002 GPIO is typically shared with the ACPI SCI the INT0002 driver must pass the same flags. This fixes the INT0002 driver failing to probe due to following error + as well as removing the backtrace that follows this error: "genirq: Flags mismatch irq 9. 00000084 (INT0002) vs. 00002080 (acpi)" Fixes: 7a36b901a6eb ("ACPI: OSL: Use a threaded interrupt handler for SCI") Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2024-02-19platform/x86: think-lmi: Fix password opcode ordering for workstationsMark Pearson1-9/+11
The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled). Tested on some Thinkpads to confirm they are OK with this order too. Signed-off-by: Mark Pearson <[email protected]> Fixes: 640a5fa50a42 ("platform/x86: think-lmi: Opcode support") Reviewed-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
2024-02-19drm/msm/dpu: add support for SDM660 and SDM630 platformsDmitry Baryshkov6-0/+524
Bring in hardware support for the SDM660 and SDM630 platforms, which belong to the same DPU generation as MSM8998. Note, by default these platforms are still handled by the MDP5 driver unless the `msm.prefer_mdp5=false' parameter is provided. Co-developed-by: Konrad Dybcio <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577507/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm: add a kernel param to select between MDP5 and DPU driversDmitry Baryshkov4-0/+38
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is possible to support this platform via the DPU driver (e.g. to provide support for DP, multirect, etc). Add a modparam to be able to switch between these two drivers. All platforms supported by both drivers are by default handled by the MDP5 driver. To let them be handled by the DPU driver pass the `msm.prefer_mdp5=false` kernel param. Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Carl Vanderlip <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577504/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/dpu: support binding to the mdp5 devicesDmitry Baryshkov3-21/+93
Existing MDP5 devices have slightly different bindings. The main register region is called `mdp_phys' instead of `mdp'. Also vbif register regions are a part of the parent, MDSS device. Add support for handling this binding differences. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577505/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/mdss: generate MDSS data for MDP5 platformsDmitry Baryshkov1-0/+51
Older (mdp5) platforms do not use per-SoC compatible strings. Instead they use a single compat entry 'qcom,mdss'. To facilitate migrating these platforms to the DPU driver provide a way to generate the MDSS / UBWC data at runtime, when the DPU driver asks for it. It is not possible to generate this data structure at the probe time, since some platforms might not have MDP_CLK enabled, which makes reading HW_REV register useless and prone to possible crashes. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577502/ Link: https://lore.kernel.org/r/[email protected]
2024-02-19drm/msm/dp: Fix spelling mistake "enale" -> "enable"Colin Ian King1-1/+1
There is a spelling mistake in a drm_dbg_dp message. Fix it. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/577760/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-02-19drm/panel: simple: Add BOE BP082WX1-100 8.2" panelTony Lindgren1-0/+20
The BOE BP082WX1-100 is a 8.2" panel similar to the 10.1" panel BP101WX1-100. Both panels use the same timings. Acked-by: Conor Dooley <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19dt-bindings: display: simple: Add boe,bp082wx1-100 8.2" panelTony Lindgren1-0/+2
This panel is found on Motorola mapphone tablets mz607 to mz609. Acked-by: Conor Dooley <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19selftests/bpf: Add negtive test cases for task iterYafang Shao2-1/+12
Incorporate a test case to assess the handling of invalid flags or task__nullable parameters passed to bpf_iter_task_new(). Prior to the preceding commit, this scenario could potentially trigger a kernel panic. However, with the previous commit, this test case is expected to function correctly. Signed-off-by: Yafang Shao <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2024-02-19bpf: Fix an issue due to uninitialized bpf_iter_taskYafang Shao1-0/+2
Failure to initialize it->pos, coupled with the presence of an invalid value in the flags variable, can lead to it->pos referencing an invalid task, potentially resulting in a kernel panic. To mitigate this risk, it's crucial to ensure proper initialization of it->pos to NULL. Fixes: ac8148d957f5 ("bpf: bpf_iter_task_next: use next_task(kit->task) rather than next_task(kit->pos)") Signed-off-by: Yafang Shao <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2024-02-19selftests/bpf: Test racing between bpf_timer_cancel_and_free and ↵Martin KaFai Lau2-2/+67
bpf_timer_cancel This selftest is based on a Alexei's test adopted from an internal user to troubleshoot another bug. During this exercise, a separate racing bug was discovered between bpf_timer_cancel_and_free and bpf_timer_cancel. The details can be found in the previous patch. This patch is to add a selftest that can trigger the bug. I can trigger the UAF everytime in my qemu setup with KASAN. The idea is to have multiple user space threads running in a tight loop to exercise both bpf_map_update_elem (which calls into bpf_timer_cancel_and_free) and bpf_timer_cancel. Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Hou Tao <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2024-02-19bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancelMartin KaFai Lau1-1/+4
The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.") Suggested-by: Alexei Starovoitov <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Hou Tao <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2024-02-19dt-bindings: display: ti,am65x-dss: Add support for common1 regionDevarsh Thakkar1-2/+5
TI keystone display subsystem present in AM65, AM62 and AM62A SoC support two separate register spaces namely "common" and "common1" which can be used by two separate hosts to program the display controller as described in respective Technical Reference Manuals [1]. The common1 register space has similar set of configuration registers as supported in common register space except the global configuration registers which are exclusive to common region. This adds binding for "common1" register region too as supported by the hardware. [1]: AM62x TRM: https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers) AM65x TRM: https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers) AM62A TRM: https://www.ti.com/lit/pdf/spruj16 (Section 14.9.9 Display Subsystem Registers) Fixes: 2d8730f1021f ("dt-bindings: display: ti,am65x-dss: Add dt-schema yaml binding") Signed-off-by: Devarsh Thakkar <[email protected]> Reviewed-by: Aradhya Bhatia <[email protected]> Acked-by: Conor Dooley <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19enic: Avoid false positive under FORTIFY_SOURCEKees Cook1-1/+2
FORTIFY_SOURCE has been ignoring 0-sized destinations while the kernel code base has been converted to flexible arrays. In order to enforce the 0-sized destinations (e.g. with __counted_by), the remaining 0-sized destinations need to be handled. Unfortunately, struct vic_provinfo resists full conversion, as it contains a flexible array of flexible arrays, which is only possible with the 0-sized fake flexible array. Use unsafe_memcpy() to avoid future false positives under CONFIG_FORTIFY_SOURCE. Signed-off-by: Kees Cook <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-19ionic: use pci_is_enabled not open codeShannon Nelson1-1/+1
Since there is a utility available for this, use the API rather than open code. Fixes: 13943d6c8273 ("ionic: prevent pci disable of already disabled device") Reviewed-by: Brett Creeley <[email protected]> Signed-off-by: Shannon Nelson <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-19btrfs: fix deadlock with fiemap and extent lockingJosef Bacik1-17/+45
While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. CC: [email protected] # 6.1+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Josef Bacik <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2024-02-19btrfs: defrag: avoid unnecessary defrag caused by incorrect extent sizeQu Wenruo1-1/+1
[BUG] With the following file extent layout, defrag would do unnecessary IO and result more on-disk space usage. # mkfs.btrfs -f $dev # mount $dev $mnt # xfs_io -f -c "pwrite 0 40m" $mnt/foobar # sync # xfs_io -f -c "pwrite 40m 16k" $mnt/foobar # sync Above command would lead to the following file extent layout: item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 41943040 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 41943040) itemoff 15763 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Which is mostly fine. We can allow the final 16K to be merged with the previous 40M, but it's upon the end users' preference. But if we defrag the file using the default parameters, it would result worse file layout: # btrfs filesystem defrag $mnt/foobar # sync item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 8650752 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 8650752) itemoff 15763 itemsize 53 generation 9 type 1 (regular) extent data disk byte 340787200 nr 33292288 extent data offset 0 nr 33292288 ram 33292288 extent compression 0 (none) item 8 key (257 EXTENT_DATA 41943040) itemoff 15710 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Note the original 40M extent is still there, but a new 32M extent is created for no benefit at all. [CAUSE] There is an existing check to make sure we won't defrag a large enough extent (the threshold is by default 32M). But the check is using the length to the end of the extent: range_len = em->len - (cur - em->start); /* Skip too large extent */ if (range_len >= extent_thresh) goto next; This means, for the first 8MiB of the extent, the range_len is always smaller than the default threshold, and would not be defragged. But after the first 8MiB, the remaining part would fit the requirement, and be defragged. Such different behavior inside the same extent caused the above problem, and we should avoid different defrag decision inside the same extent. [FIX] Instead of using @range_len, just use @em->len, so that we have a consistent decision among the same file extent. Now with this fix, we won't touch the extent, thus not making it any worse. Reported-by: Filipe Manana <[email protected]> Fixes: 0cb5950f3f3b ("btrfs: fix deadlock when reserving space during defrag") CC: [email protected] # 6.1+ Reviewed-by: Boris Burkov <[email protected]> Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
2024-02-19drm/tests/drm_buddy: fix 32b buildMatthew Auld1-8/+8
Doesn't seem to compile on 32b, presumably due to u64 mod/division. Simplest is to just switch over to u32 here. Also make print modifiers consistent with that. Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Arunpravin Paneer Selvam <[email protected]> Cc: Christian König <[email protected]> Cc: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]>
2024-02-19accel/ivpu: Rename VPU to NPU in message stringsJacek Lawrynowicz7-22/+22
VPU was renamed to NPU but due to large overhead of renaming all the sources only user visible messages are being updated. Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Refactor BO creation functionsWachowski, Karol5-60/+71
Rename BO allocate/create functions, so the code is more consistent. There are now two matching buffer creation functions: - ivpu_bo_create_ioctl() - create a BO from user space - ivpu_bo_create() - create a BO from kernel space ivpu_bo_alloc() is now only used to allocate struct ivpu_bo which better matches its name. Signed-off-by: Wachowski, Karol <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Fix ivpu_reset_engine_fn merge issueJacek Lawrynowicz1-16/+16
ivpu_reset_engine_fn and ivpu_reset_engine_fops were separated during merge so move them back together to keep the file consistent. Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Use lazy allocation for doorbell IDsWachowski, Karol3-3/+22
Reserve/allocate and free doorbells for command queues when needed using xarray. This allows to avoid reserving a doorbell for a contexts that never issues a job. Signed-off-by: Wachowski, Karol <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Add support for FW boot param system_time_usKrystian Pradzynski1-0/+6
Add support for FW boot API param system_time_us. According to the API description this field should be set to system time in microseconds starting from 1970. Signed-off-by: Krystian Pradzynski <[email protected]> Signed-off-by: Jacek Lawrynowicz <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Update FW API headersJacek Lawrynowicz2-23/+55
Update Boot API to 3.22.0 and JSM API to 3.15.6 Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Remove legacy firmware nameJacek Lawrynowicz1-2/+0
We are now using NPU IP generation based FW names instead of platform code names, so mtl_vpu.bin can be removed. Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19accel/ivpu: Rename TILE_SKU_BOTH_MTL to TILE_SKU_BOTHJacek Lawrynowicz1-2/+2
Remove legacy postfix from TILE_SKU_BOTH macro. This was missed when renaming MTL to VPU37XX. Signed-off-by: Jacek Lawrynowicz <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-19ata: ahci_ceva: fix error handling for Xilinx GT PHY supportRadhey Shyam Pandey1-46/+79
Platform clock and phy error resources are not cleaned up in Xilinx GT PHY error path. To fix introduce the function ceva_ahci_platform_enable_resources() which is a customized version of ahci_platform_enable_resources() and inline with SATA IP programming sequence it does: - Assert SATA reset - Program PS GTR phy - Bring SATA by de-asserting the reset - Wait for GT lane PLL to be locked ceva_ahci_platform_enable_resources() is also used in the resume path as the same SATA programming sequence (as in probe) should be followed. Also cleanup the mixed usage of ahci_platform_enable_resources() and custom implementation in the probe function as both are not required. Fixes: 9a9d3abe24bb ("ata: ahci: ceva: Update the driver to support xilinx GT phy") Signed-off-by: Radhey Shyam Pandey <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Niklas Cassel <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.