CVE-2024-57888

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker<br /> <br /> After commit<br /> 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")<br /> amdgpu started seeing the following warning:<br /> <br /> [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]<br /> ...<br /> [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]<br /> ...<br /> [ ] Call Trace:<br /> [ ] <br /> ...<br /> [ ] ? check_flush_dependency+0xf5/0x110<br /> ...<br /> [ ] cancel_delayed_work_sync+0x6e/0x80<br /> [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]<br /> [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu]<br /> [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu]<br /> [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]<br /> [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu]<br /> [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched]<br /> [ ] process_one_work+0x217/0x720<br /> ...<br /> [ ] <br /> <br /> The intent of the verifcation done in check_flush_depedency is to ensure<br /> forward progress during memory reclaim, by flagging cases when either a<br /> memory reclaim process, or a memory reclaim work item is flushed from a<br /> context not marked as memory reclaim safe.<br /> <br /> This is correct when flushing, but when called from the<br /> cancel(_delayed)_work_sync() paths it is a false positive because work is<br /> either already running, or will not be running at all. Therefore<br /> cancelling it is safe and we can relax the warning criteria by letting the<br /> helper know of the calling context.<br /> <br /> References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")