summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-08-26xfs: do not propagate ENODATA disk errors into xattr codeEric Sandeen
ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found. However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as "attribute not found" when in fact it's an IO (disk) error. At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; } because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfs_trans_brelse will then null-deref it. As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO. However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later. (Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.) Signed-off-by: Eric Sandeen <sandeen@redhat.com> Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") Cc: stable@vger.kernel.org # v5.9+ Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2025-08-26ALSA: usb-audio: us144mkii: Fixes for handshake, MIDI out and cleanupŠerif Rami
Add a handshake value of 0x32, which is required when the device was previously used by another OS with the official drivers. Correct the last byte of the MIDI output protocol to 0xe0. Also, remove the unused DRIVER_VERSION macro. Signed-off-by: Šerif Rami <ramiserifpersia@gmail.com> Link: https://patch.msgid.link/20250825072557.7670-1-ramiserifpersia@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-08-26sched/deadline: Don't count nr_running for dl_server proxy tasksYicong Yang
On CPU offline the kernel stalled with below call trace: INFO: task kworker/0:1:11 blocked for more than 120 seconds. cpuhp hold the cpu hotplug lock endless and stalled vmstat_shepherd. This is because we count nr_running twice on cpuhp enqueuing and failed the wait condition of cpuhp: enqueue_task_fair() // pick cpuhp from idle, rq->nr_running = 0 dl_server_start() [...] add_nr_running() // rq->nr_running = 1 add_nr_running() // rq->nr_running = 2 [switch to cpuhp, waiting on balance_hotplug_wait()] rcuwait_wait_event(rq->nr_running == 1 && ...) // failed, rq->nr_running=2 schedule() // wait again It doesn't make sense to count the dl_server towards runnable tasks, since it runs other tasks. Fixes: 63ba8422f876 ("sched/deadline: Introduce deadline servers") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250627035420.37712-1-yangyicong@huawei.com
2025-08-26sched/deadline: Fix RT task potential starvation when expiry time passedkuyo chang
[Symptom] The fair server mechanism, which is intended to prevent fair starvation when higher-priority tasks monopolize the CPU. Specifically, RT tasks on the runqueue may not be scheduled as expected. [Analysis] The log "sched: DL replenish lagged too much" triggered. By memory dump of dl_server: curr = 0xFFFFFF80D6A0AC00 ( dl_server = 0xFFFFFF83CD5B1470( dl_runtime = 0x02FAF080, dl_deadline = 0x3B9ACA00, dl_period = 0x3B9ACA00, dl_bw = 0xCCCC, dl_density = 0xCCCC, runtime = 0x02FAF080, deadline = 0x0000082031EB0E80, flags = 0x0, dl_throttled = 0x0, dl_yielded = 0x0, dl_non_contending = 0x0, dl_overrun = 0x0, dl_server = 0x1, dl_server_active = 0x1, dl_defer = 0x1, dl_defer_armed = 0x0, dl_defer_running = 0x1, dl_timer = ( node = ( expires = 0x000008199756E700), _softexpires = 0x000008199756E700, function = 0xFFFFFFDB9AF44D30 = dl_task_timer, base = 0xFFFFFF83CD5A12C0, state = 0x0, is_rel = 0x0, is_soft = 0x0, clock_update_flags = 0x4, clock = 0x000008204A496900, - The timer expiration time (rq->curr->dl_server->dl_timer->expires) is already in the past, indicating the timer has expired. - The timer state (rq->curr->dl_server->dl_timer->state) is 0. [Suspected Root Cause] The relevant code flow in the throttle path of update_curr_dl_se() as follows: dequeue_dl_entity(dl_se, 0); // the DL entity is dequeued if (unlikely(is_dl_boosted(dl_se) || !start_dl_timer(dl_se))) { if (dl_server(dl_se)) // timer registration fails enqueue_dl_entity(dl_se, ENQUEUE_REPLENISH);//enqueue immediately ... } The failure of `start_dl_timer` is caused by attempting to register a timer with an expiration time that is already in the past. When this situation persists, the code repeatedly re-enqueues the DL entity without properly replenishing or restarting the timer, resulting in RT task may not be scheduled as expected. [Proposed Solution]: Instead of immediately re-enqueuing the DL entity on timer registration failure, this change ensures the DL entity is properly replenished and the timer is restarted, preventing RT potential starvation. Fixes: 63ba8422f876 ("sched/deadline: Introduce deadline servers") Signed-off-by: kuyo chang <kuyo.chang@mediatek.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Closes: https://lore.kernel.org/CAMuHMdXn4z1pioTtBGMfQM0jsLviqS2jwysaWXpoLxWYoGa82w@mail.gmail.com Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lkml.kernel.org/r/20250615131129.954975-1-kuyo.chang@mediatek.com
2025-08-26sched/deadline: Always stop dl-server before changing parametersJuri Lelli
Commit cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling") reduced dl-server overhead by delaying disabling servers only after there are no fair task around for a whole period, which means that deadline entities are not dequeued right away on a server stop event. However, the delay opens up a window in which a request for changing server parameters can break per-runqueue running_bw tracking, as reported by Yuri. Close the problematic window by unconditionally calling dl_server_stop() before applying the new parameters (ensuring deadline entities go through an actual dequeue). Fixes: cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling") Reported-by: Yuri Andriaccio <yurand2000@gmail.com> Signed-off-by: Juri Lelli <juri.lelli@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Valentin Schneider <vschneid@redhat.com> Link: https://lore.kernel.org/r/20250721-upstream-fix-dlserver-lessaggressive-b4-v1-1-4ebc10c87e40@redhat.com
2025-08-26sched/deadline: Fix dl_server_stopped()Huacai Chen
Commit cccb45d7c429 ("sched/deadline: Less agressive dl_server handling") introduces dl_server_stopped(). But it is obvious that dl_server_stopped() should return true if dl_se->dl_server_active is 0. Fixes: cccb45d7c429 ("sched/deadline: Less agressive dl_server handling") Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20250809130419.1980742-1-chenhuacai@loongson.cn
2025-08-26Revert "drm/tegra: Use dma_buf from GEM object instance"Thomas Zimmermann
This reverts commit 482c7e296edc0f594e8869a789a40be53c49bd6a. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20250715084549.41473-1-tzimmermann@suse.de
2025-08-26ALSA: hda/hdmi: Restore missing HDMI codec entriesDaniel Dadap
Commit ad781b550f9a ("ALSA: hda/hdmi: Rewrite to new probe method") rewrote the HDMI codec ID tables to a new format. In doing so, recently added codec IDs from commit e0a911ac868 ("ALSA: hda: Add missing NVIDIA HDA codec IDs") were dropped from the tables. These tables had recently been split from the unified table that existed in patch_hdmi.c, and did contain the entries in question after the split but before the codec ID entries were rewritten to the new format. Restore the missing codec ID entries to nvhdmi.c and tegrahdmi.c. There do not appear to be any additional missing entries in any of the other codec ID tables when compared to the patch_hdmi.c at the final revision before the split. Fixes: ad781b550f9a ("ALSA: hda/hdmi: Rewrite to new probe method") Signed-off-by: Daniel Dadap <ddadap@nvidia.com> Link: https://patch.msgid.link/aK0ghvagXy740rxd@ddadap-lakeline.nvidia.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-08-26drm/vesadrm: Support DRM_FORMAT_C8Thomas Zimmermann
Add support for DRM_FORMAT_C8 to vesadrm. The new pixel-format description PIXEL_FORMAT_C8 describes the layout. Vesadrm's helpers vesadrm_fill_palette_lut() and vesadrm_load_palette_lut() set the hardware palette according to the CRTC's output format. The driver emulates XRGB8888 by converting the source buffer to RGB332 and using the resulting 256 colors as index into the hardware palette. The hardware palette converts back to RGB during scanout. This has no overhead compared to other format conversion, but allows common userspace, such as Wayland compositors, to operate on the display. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-10-tzimmermann@suse.de
2025-08-26drm/vesadrm: Prepare color management for palette-based framebuffersThomas Zimmermann
Distiguish between component-based formats and 'the rest' in vesadrm's color management. Scanout buffers with component-based format allow for gamma correction. Palette-based formats (i.e., 'the rest') require palette setup. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-9-tzimmermann@suse.de
2025-08-26drm/vesadrm: Rename vesadrm_set_gamma_lut() to vesadrm_set_color_lut()Thomas Zimmermann
Rename vesadrm's gamma helpers in preparation of the upcoming support for color palettes. Gamma correction and color palettes share the same hardware features, but the driver's old naming only indicated support for gamma LUTs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-8-tzimmermann@suse.de
2025-08-26drm/format-helper: Add XRGB8888-to-RGB332 to drm_fb_blit()Thomas Zimmermann
List the conversion from XRGB8888-to-RGB332 in drm_fb_blit(), so that drivers based on sysfb-helpers can use it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-7-tzimmermann@suse.de
2025-08-26drm/color-mgmt: Prepare for RGB332 palettesThomas Zimmermann
Add helper drm_crtc_fill_palette_332(), which fills palettes with RGB332 color data. Each color in RGB332 format serves as an index into an 8-bit palette that stores the corresponding component-based colors. Vesadrm will use the new helper to emulate RGB formats on top of framebuffers in C8 format. v2: - add comments on bit operations (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-6-tzimmermann@suse.de
2025-08-26drm/sysfb: Blit to CRTC destination formatThomas Zimmermann
Use the color format stored in struct drm_sysfb_crtc_state for color-format conversion instead of the scanout-buffer format announced by firmware. Currently, both values are identical. This will allow drivers to modify the CRTC's input format to a certain extend. Specifically, vesadrm will be able to display RGB framebuffers when the scanout buffer is of C8 format. With color- format conversion to RGB332 and correct setup of the C8 palette, displaying XRGB8888-based buffers under C8 can be achieved. v2: - refer to RGB332 as CRTC input format Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-5-tzimmermann@suse.de
2025-08-26drm/sysfb: Find screen_info format with helpersThomas Zimmermann
Convert drm_sysfb_get_format_si() to lookup the screen_info color format as struct pixel_format with screen_info_pixel_format(). Then search the list of given formats for the screen_info format with pixel_format_equal(). Replaces custom code with helpers. The pixel-compare helper pixel_format_equal() also handles indexed color formats. Prepares for sysfb drivers to support color palettes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-4-tzimmermann@suse.de
2025-08-26video: screen_info: Add pixel-format helper for linear framebuffersThomas Zimmermann
Add screen_info_pixel_format(), which converts a screen_info's information about the color format to struct pixel_format. The encoding within the screen_info structure is complex and therefore prone to errors. Later patches will convert callers to use the pixel format. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-3-tzimmermann@suse.de
2025-08-26video: pixel_format: Add compare helpersThomas Zimmermann
Add helpers that compare two pixel-format descriptions against each other. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-2-tzimmermann@suse.de
2025-08-26perf: Skip user unwind if the task is a kernel threadJosh Poimboeuf
If the task is not a user thread, there's no user stack to unwind. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250820180428.930791978@kernel.org
2025-08-26perf: Simplify get_perf_callchain() user logicJosh Poimboeuf
Simplify the get_perf_callchain() user logic a bit. task_pt_regs() should never be NULL. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20250820180428.760066227@kernel.org
2025-08-26perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of current->mm ↵Steven Rostedt
== NULL To determine if a task is a kernel thread or not, it is more reliable to use (current->flags & (PF_KTHREAD|PF_USER_WORKERi)) than to rely on current->mm being NULL. That is because some kernel tasks (io_uring helpers) may have a mm field. Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250820180428.592367294@kernel.org
2025-08-26perf: Have get_perf_callchain() return NULL if crosstask and user are setJosh Poimboeuf
get_perf_callchain() doesn't support cross-task unwinding for user space stacks, have it return NULL if both the crosstask and user arguments are set. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250820180428.426423415@kernel.org
2025-08-26perf: Remove get_perf_callchain() init_nr argumentJosh Poimboeuf
The 'init_nr' argument has double duty: it's used to initialize both the number of contexts and the number of stack entries. That's confusing and the callers always pass zero anyway. Hard code the zero. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <Namhyung@kernel.org> Acked-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20250820180428.259565081@kernel.org
2025-08-26memblock: fix kernel-doc for MEMBLOCK_RSRV_NOINITMike Rapoport (Microsoft)
The kernel-doc description of MEMBLOCK_RSRV_NOINIT and memblock_reserved_mark_noinit() do not accurately describe their functionality. Expand their kernel doc to make it clear that the user of MEMBLOCK_RSRV_NOINIT is responsible to properly initialize the struct pages for such regions and add more details about effects of using this flag. Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/f8140a17-c4ec-489b-b314-d45abe48bf36@redhat.com Link: https://lore.kernel.org/r/20250826071947.1949725-1-rppt@kernel.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
2025-08-26ibmvnic: Increase max subcrq indirect entries with fallbackMingming Cao
POWER8 support a maximum of 16 subcrq indirect descriptor entries per H_SEND_SUB_CRQ_INDIRECT call, while POWER9 and newer hypervisors support up to 128 entries. Increasing the max number of indirect descriptor entries improves batching efficiency and reduces hcall overhead, which enhances throughput under large workload on POWER9+. Currently, ibmvnic driver always uses a fixed number of max indirect descriptor entries (16). send_subcrq_indirect() treats all hypervisor errors the same: - Cleanup and Drop the entire batch of descriptors. - Return an error to the caller. - Rely on TCP/IP retransmissions to recover. - If the hypervisor returns H_PARAMETER (e.g., because 128 entries are not supported on POWER8), the driver will continue to drop batches, resulting in unnecessary packet loss. In this patch: Raise the default maximum indirect entries to 128 to improve ibmvnic batching on morden platform. But also gracefully fall back to 16 entries for Power 8 systems. Since there is no VIO interface to query the hypervisor’s supported limit, vnic handles send_subcrq_indirect() H_PARAMETER errors: - On first H_PARAMETER failure, log the failure context - Reduce max_indirect_entries to 16 and allow the single batch to drop. - Subsequent calls automatically use the correct lower limit, avoiding repeated drops. The goal is to optimizes performance on modern systems while handles falling back for older POWER8 hypervisors. Performance shows 40% improvements with MTU (1500) on largework load. Signed-off-by: Mingming Cao <mmc@linux.ibm.com> Reviewed-by: Brian King <bjking1@linux.ibm.com> Reviewed-by: Haren Myneni <haren@linux.ibm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250821130215.97960-1-mmc@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-08-26virtio_net: adjust the execution order of function `virtnet_close` during freezeJunnan Wu
"Use after free" issue appears in suspend once race occurs when napi poll scheduls after `netif_device_detach` and before napi disables. For details, during suspend flow of virtio-net, the tx queue state is set to "__QUEUE_STATE_DRV_XOFF" by CPU-A. And at some coincidental times, if a TCP connection is still working, CPU-B does `virtnet_poll` before napi disable. In this flow, the state "__QUEUE_STATE_DRV_XOFF" of tx queue will be cleared. This is not the normal process it expects. After that, CPU-A continues to close driver then virtqueue is removed. Sequence likes below: -------------------------------------------------------------------------- CPU-A CPU-B ----- ----- suspend is called A TCP based on virtio-net still work virtnet_freeze |- virtnet_freeze_down | |- netif_device_detach | | |- netif_tx_stop_all_queues | | |- netif_tx_stop_queue | | |- set_bit | | (__QUEUE_STATE_DRV_XOFF,...) | | softirq rasied | | |- net_rx_action | | |- napi_poll | | |- virtnet_poll | | |- virtnet_poll_cleantx | | |- netif_tx_wake_queue | | |- test_and_clear_bit | | (__QUEUE_STATE_DRV_XOFF,...) | |- virtnet_close | |- virtnet_disable_queue_pair | |- virtnet_napi_tx_disable |- remove_vq_common -------------------------------------------------------------------------- When TCP delayack timer is up, a cpu gets softirq and irq handler `tcp_delack_timer_handler` will be called, which will finally call `start_xmit` in virtio net driver. Then the access to tx virtq will cause panic. The root cause of this issue is that napi tx is not disable before `netif_tx_stop_queue`, once `virnet_poll` schedules in such coincidental time, the tx queue state will be cleared. To solve this issue, adjusts the order of function `virtnet_close` in `virtnet_freeze_down`. Co-developed-by: Ying Xu <ying123.xu@samsung.com> Signed-off-by: Ying Xu <ying123.xu@samsung.com> Signed-off-by: Junnan Wu <junnan01.wu@samsung.com> Message-Id: <20250812090817.3463403-1-junnan01.wu@samsung.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-26virtio_input: Improve freeze handlingYing Gao
When executing suspend to ram, if lacking the operations to reset device and free unused buffers before deleting a vq, resource leaks and inconsistent device status will appear. According to chapter "3.3.1 Driver Requirements: Device Cleanup:" of virtio-specification: Driver MUST ensure a virtqueue isn’t live (by device reset) before removing exposed buffers. Therefore, modify the virtinput_freeze function to reset the device and delete the unused buffers before deleting the virtqueue, just like virtinput_remove does. Co-developed-by: Ying Xu <ying123.xu@samsung.com> Signed-off-by: Ying Xu <ying123.xu@samsung.com> Co-developed-by: Junnan Wu <junnan01.wu@samsung.com> Signed-off-by: Junnan Wu <junnan01.wu@samsung.com> Signed-off-by: Ying Gao <ying01.gao@samsung.com> Message-Id: <20250812095118.3622717-1-ying01.gao@samsung.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-26vhost: Fix ioctl # for VHOST_[GS]ET_FORK_FROM_OWNERNamhyung Kim
The VHOST_[GS]ET_FEATURES_ARRAY ioctl already took 0x83 and it would result in a build error when the vhost uapi header is used for perf tool build like below. In file included from trace/beauty/ioctl.c:93: tools/perf/trace/beauty/generated/ioctl/vhost_virtio_ioctl_array.c: In function ‘ioctl__scnprintf_vhost_virtio_cmd’: tools/perf/trace/beauty/generated/ioctl/vhost_virtio_ioctl_array.c:36:18: error: initialized field overwritten [-Werror=override-init] 36 | [0x83] = "SET_FORK_FROM_OWNER", | ^~~~~~~~~~~~~~~~~~~~~ tools/perf/trace/beauty/generated/ioctl/vhost_virtio_ioctl_array.c:36:18: note: (near initialization for ‘vhost_virtio_ioctl_cmds[131]’) Fixes: 7d9896e9f6d02d8a ("vhost: Reintroduce kthread API and add mode selection") Signed-off-by: Namhyung Kim <namhyung@kernel.org> Message-Id: <20250819063958.833770-1-namhyung@kernel.org> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com>
2025-08-26Revert "virtio: reject shm region if length is zero"Igor Torrente
The commit 206cc44588f7 ("virtio: reject shm region if length is zero") breaks the Virtio-gpu `host_visible` feature. As you can see in the snippet below, host_visible_region is zero because of the `kzalloc`. It's using the `vm_get_shm_region` (drivers/virtio/virtio_mmio.c:536) to read the `addr` and `len` from qemu/crosvm. ``` drivers/gpu/drm/virtio/virtgpu_kms.c 132 vgdev = drmm_kzalloc(dev, sizeof(struct virtio_gpu_device), GFP_KERNEL); [...] 177 if (virtio_get_shm_region(vgdev->vdev, &vgdev->host_visible_region, 178 VIRTIO_GPU_SHM_ID_HOST_VISIBLE)) { ``` Now it always fails. To fix, revert the offending commit. Fixes: 206cc44588f7 ("virtio: reject shm region if length is zero") Signed-off-by: Igor Torrente <igor.torrente@collabora.com> Message-Id: <20250807124145.81816-1-igor.torrente@collabora.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-26vhost/net: Protect ubufs with rcu read lock in vhost_net_ubuf_put()Nikolay Kuratov
When operating on struct vhost_net_ubuf_ref, the following execution sequence is theoretically possible: CPU0 is finalizing DMA operation CPU1 is doing VHOST_NET_SET_BACKEND // ubufs->refcount == 2 vhost_net_ubuf_put() vhost_net_ubuf_put_wait_and_free(oldubufs) vhost_net_ubuf_put_and_wait() vhost_net_ubuf_put() int r = atomic_sub_return(1, &ubufs->refcount); // r = 1 int r = atomic_sub_return(1, &ubufs->refcount); // r = 0 wait_event(ubufs->wait, !atomic_read(&ubufs->refcount)); // no wait occurs here because condition is already true kfree(ubufs); if (unlikely(!r)) wake_up(&ubufs->wait); // use-after-free This leads to use-after-free on ubufs access. This happens because CPU1 skips waiting for wake_up() when refcount is already zero. To prevent that use a read-side RCU critical section in vhost_net_ubuf_put(), as suggested by Hillf Danton. For this lock to take effect, free ubufs with kfree_rcu(). Cc: stable@vger.kernel.org Fixes: 0ad8b480d6ee9 ("vhost: fix ref cnt checking deadlock") Reported-by: Andrey Ryabinin <arbn@yandex-team.com> Suggested-by: Hillf Danton <hdanton@sina.com> Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru> Message-Id: <20250805130917.727332-1-kniv@yandex-team.ru> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-26virtio_pci: Fix misleading comment for queue vectorLiming Wu
This patch fixes misleading comments in both legacy and modern virtio-pci device implementations. The comments previously referred to the "config vector" for parameters and return values of the `vp_legacy_queue_vector()` and `vp_modern_queue_vector()` functions, which is incorrect. Signed-off-by: Liming Wu <liming.wu@jaguarmicro.com> Message-Id: <20250731092757.1000-1-liming.wu@jaguarmicro.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2025-08-26octeontx2-af: Remove unused declarationsYue Haibing
Commit 1845ada47f6d ("octeontx2-af: cn10k: Add RPM LMAC pause frame support") remove cgx_lmac_[s|g]et_pause_frm() and leave these unused. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://patch.msgid.link/20250820123007.1705047-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-08-26drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WAJouni Högander
We are currently removing underrun on idle PSR WA even if it's not applied. Fix this by checking pkg_c_latency_used on PSR exit as well. Fixes: 9b1795e9b0ae ("drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblank") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://lore.kernel.org/r/20250822105846.1023631-1-jouni.hogander@intel.com
2025-08-26thunderbolt: Use string choices helpersChelsy Ratnawat
Use string_choices.h helpers instead of hard-coded strings. Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-08-26drm/xe/uapi: Add UAPI for querying VMA count and memory attributesHimal Prasad Ghimiray
Introduce the DRM_IOCTL_XE_VM_QUERY_MEMORY_RANGE_ATTRS ioctl to allow userspace to query memory attributes of VMAs within a user specified virtual address range. Userspace first calls the ioctl with num_mem_ranges = 0, sizeof_mem_ranges_attr = 0 and vector_of_vma_mem_attr = NULL to retrieve the number of memory ranges (vmas) and size of each memory range attribute. Then, it allocates a buffer of that size and calls the ioctl again to fill the buffer with memory range attributes. This two-step interface allows userspace to first query the required buffer size, then retrieve detailed attributes efficiently. v2 (Matthew Brost) - Use same ioctl to overload functionality v3 - Add kernel-doc v4 - Make uapi future proof by passing struct size (Matthew Brost) - make lock interruptible (Matthew Brost) - set reserved bits to zero (Matthew Brost) - s/__copy_to_user/copy_to_user (Matthew Brost) - Avod using VMA term in uapi (Thomas) - xe_vm_put(vm) is missing (Shuicheng) v5 - Nits - Fix kernel-doc Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-21-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Enable madvise ioctl for xeHimal Prasad Ghimiray
Ioctl enables setting up of memory attributes in user provided range. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-20-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Reset VMA attributes to default in SVM garbage collectorHimal Prasad Ghimiray
Restore default memory attributes for VMAs during garbage collection if they were modified by madvise. Reuse existing VMA if fully overlapping; otherwise, allocate a new mirror VMA. v2 (Matthew Brost) - Add helper for vma split - Add retry to get updated vma v3 - Rebase on gpuvm layer Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-19-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/vm: Add helper to check for default VMA memory attributesHimal Prasad Ghimiray
Introduce a new helper function `xe_vma_has_default_mem_attrs()` to determine whether a VMA's memory attributes are set to their default values. This includes checks for atomic access, PAT index, and preferred location. Also, add a new field `default_pat_index` to `struct xe_vma_mem_attr` to track the initial PAT index set during the first bind. This helps distinguish between default and user-modified pat index, such as those changed via madvise. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-18-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/madvise: Skip vma invalidation if mem attr are unchangedHimal Prasad Ghimiray
If a VMA within the madvise input range already has the same memory attribute as the one requested by the user, skip PTE zapping for that VMA to avoid unnecessary invalidation. v2 (Matthew Brost) - fix skip_invalidation for new attributes - s/u32/bool - Remove unnecessary assignment for kzalloc'ed Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-17-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/bo: Update atomic_access attribute on madviseHimal Prasad Ghimiray
Update the bo_atomic_access based on user-provided input and determine the migration to smem during a CPU fault v2 (Matthew Brost) - Avoid cpu unmapping if bo is already in smem - check atomics on smem too for ioctl - Add comments v3 - Avoid migration in prefetch v4 (Matthew Brost) - make sanity check function bool - add assert for smem placement - fix doc v5 (Matthew Brost) - NACK atomic fault with DRM_XE_ATOMIC_CPU Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-16-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/bo: Add attributes field to xe_boHimal Prasad Ghimiray
A single BO can be linked to multiple VMAs, making VMA attributes insufficient for determining the placement and PTE update attributes of the BO. To address this, an attributes field has been added to the BO. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-15-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Consult madvise preferred location in prefetchHimal Prasad Ghimiray
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC, prefetch svm ranges to preferred location provided by madvise. v2 (Matthew Brost) - Fix region, devmem_fd usages - consult madvise is applicable for other vma's too. v3 - Fix atomic handling v4 - Fix xe_svm_range_validate to check for DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC too. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-14-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/uapi: Add flag for consulting madvise hints on svm prefetchHimal Prasad Ghimiray
Introduce flag DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC to ensure prefetching in madvise-advised memory regions v2 (Matthew Brost) - Add kernel-doc v3 (Matthew Brost) - Fix kernel-doc Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-13-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Support DRM_XE_SVM_MEM_RANGE_ATTR_PAT memory attributeHimal Prasad Ghimiray
This attributes sets the pat_index for the svm used vma range, which is utilized to ascertain the coherence. v2 (Matthew Brost) - Pat index sanity check Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-12-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/madvise: Update migration policy based on preferred locationHimal Prasad Ghimiray
When the user sets the valid devmem_fd as a preferred location, GPU fault will trigger migration to tile of device associated with devmem_fd. If the user sets an invalid devmem_fd the preferred location is current placement(smem) only. v2(Matthew Brost) - Default should be faulting tile - remove devmem_fd used as region v3 (Matthew Brost) - Add migration_policy - Fix return condition - fix migrate condition v4 -Rebase v5 - Add check for userptr and bo based vmas Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-11-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Add svm ranges migration policy on atomic accessHimal Prasad Ghimiray
If the platform does not support atomic access on system memory, and the ranges are in system memory, but the user requires atomic accesses on the VMA, then migrate the ranges to VRAM. Apply this policy for prefetch operations as well. v2 - Drop unnecessary vm_dbg v3 (Matthew Brost) - fix atomic policy - prefetch shouldn't have any impact of atomic - bo can be accessed from vma, avoid duplicate parameter v4 (Matthew Brost) - Remove TODO comment - Fix comment - Dont allow gpu atomic ops when user is setting atomic attr as CPU v5 (Matthew Brost) - Fix atomic checks - Add userptr checks Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-10-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Implement madvise ioctl for xeHimal Prasad Ghimiray
This driver-specific ioctl enables UMDs to control the memory attributes for GPU VMAs within a specified input range. If the start or end addresses fall within an existing VMA, the VMA is split accordingly. The attributes of the VMA are modified as provided by the users. The old mappings of the VMAs are invalidated, and TLB invalidation is performed if necessary. v2(Matthew brost) - xe_vm_in_fault_mode can't be enabled by Mesa, hence allow ioctl in non fault mode too - fix tlb invalidation skip for same ranges in multiple op - use helper for tlb invalidation - use xe_svm_notifier_lock/unlock helper - s/lockdep_assert_held/lockdep_assert_held_write - Add kernel-doc v3(Matthew Brost) - make vfunc fail safe - Add sanitizing input args before vfunc v4(Matthew Brost/Shuicheng) - Make locks interruptable - Error handling fixes - vm_put fixes v5(Matthew Brost) - Flush garbage collector before any locking. - Add check for null vma Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-9-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zappingHimal Prasad Ghimiray
Introduce xe_svm_ranges_zap_ptes_in_range(), a function to zap page table entries (PTEs) for all SVM ranges within a user-specified address range. -v2 (Matthew Brost) Lock should be called even for tlb_invalidation v3(Matthew Brost) - Update comment - s/notifier->itree.start/drm_gpusvm_notifier_start - s/notifier->itree.last + 1/drm_gpusvm_notifier_end - use WRITE_ONCE Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-8-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Allow CPU address mirror VMA unbind with gpu bindings for madviseHimal Prasad Ghimiray
In the case of the MADVISE ioctl, if the start or end addresses fall within a VMA and existing SVM ranges are present, remove the existing SVM mappings. Then, continue with ops_parse to create new VMAs by REMAP unmapping of old one. v2 (Matthew Brost) - Use vops flag to call unmapping of ranges in vm_bind_ioctl_ops_parse - Rename the function v3 - Fix doc v4 - check if range is already in garbage collector (Matthew Brost) Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-7-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Split system allocator vma incase of madvise callHimal Prasad Ghimiray
If the start or end of input address range lies within system allocator vma split the vma to create new vma's as per input range. v2 (Matthew Brost) - Add lockdep_assert_write for vm->lock - Remove unnecessary page aligned checks - Add kerrnel-doc and comments - Remove unnecessary unwind_ops and return v3 - Fix copying of attributes v4 - Nit fixes v5 - Squash identifier for madvise in xe_vma_ops to this patch v6/v7/v8 - Rebase on drm_gpuvm changes Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-6-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameterHimal Prasad Ghimiray
This change simplifies the logic by ensuring that remapped previous or next VMAs are created with the same memory attributes as the original VMA. By passing struct xe_vma_mem_attr as a parameter, we maintain consistency in memory attributes. -v2 *dst = *src (Matthew Brost) -v3 (Matthew Brost) Drop unnecessary helper pass attr ptr as input to new_vma and vma_create Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-5-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
generated by cgit v1.3 (git 2.53.0) at 2026-11-15 21:09:43 +0000