From: Tejun Heo <tj@kernel.org>
To: Tvrtko Ursulin <tursulin@igalia.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
kernel-dev@igalia.com, linux-kernel@vger.kernel.org,
Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
Peter Zijlstra <peterz@infradead.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Alex Deucher <alexander.deucher@amd.com>,
Matthew Brost <matthew.brost@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH] workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker
Date: Thu, 19 Dec 2024 06:15:26 -1000 [thread overview]
Message-ID: <Z2RGnlAUB4vsXYCi@slm.duckdns.org> (raw)
In-Reply-To: <20241219093030.52080-1-tursulin@igalia.com>
On Thu, Dec 19, 2024 at 09:30:30AM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>
> After commit
> 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
> amdgpu started seeing the following warning:
>
> [ ] 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]
> ...
> [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]
> ...
> [ ] Call Trace:
> [ ] <TASK>
> ...
> [ ] ? check_flush_dependency+0xf5/0x110
> ...
> [ ] cancel_delayed_work_sync+0x6e/0x80
> [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]
> [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu]
> [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu]
> [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]
> [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu]
> [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched]
> [ ] process_one_work+0x217/0x720
> ...
> [ ] </TASK>
>
> The intent of the verifcation done in check_flush_depedency is to ensure
> forward progress during memory reclaim, by flagging cases when either a
> memory reclaim process, or a memory reclaim work item is flushed from a
> context not marked as memory reclaim safe.
>
> This is correct when flushing, but when called from the
> cancel(_delayed)_work_sync() paths it is a false positive because work is
> either already running, or will not be running at all. Therefore
> cancelling it is safe and we can relax the warning criteria by letting the
> helper know of the calling context.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Fixes: fca839c00a12 ("workqueue: warn if memory reclaim tries to flush !WQ_MEM_RECLAIM workqueue")
> References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: <stable@vger.kernel.org> # v4.5+
Applied to wq/for-6.13-fixes.
Thanks.
--
tejun
prev parent reply other threads:[~2024-12-19 16:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-19 9:30 [PATCH] workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker Tvrtko Ursulin
2024-12-19 16:15 ` Tejun Heo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z2RGnlAUB4vsXYCi@slm.duckdns.org \
--to=tj@kernel.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jiangshanlai@gmail.com \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tursulin@igalia.com \
--cc=tvrtko.ursulin@igalia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.