From: sashiko-bot@kernel.org
To: "Karol Wachowski" <karol.wachowski@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] accel/ivpu: Abort pending jobs on file close
Date: Mon, 14 Sep 2026 08:48:48 +0000 [thread overview]
Message-ID: <20260914084849.706A01F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260914082929.892437-1-karol.wachowski@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Context and job cleanup is skipped when CONFIG_PM is disabled, defeating the purpose of the patch.
--
commit e999c7cb2698f3a8d3e0b1deb6b6b334895bbf3e
Author: Karol Wachowski <karol.wachowski@linux.intel.com>
accel/ivpu: Abort pending jobs on file close
This commit modifies ivpu_postclose() to explicitly abort a context's command
queues and signal all pending jobs. This ensures that any in-flight jobs do
not keep running in the background after the owning process exits.
> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> index 0f215392d42de..4c73dc8b3aafe 100644
> --- a/drivers/accel/ivpu/ivpu_drv.c
> +++ b/drivers/accel/ivpu/ivpu_drv.c
> @@ -393,6 +393,17 @@ static void ivpu_postclose(struct drm_device *dev, struct drm_file *file)
> ivpu_dbg(vdev, FILE, "file_priv close: ctx %u process %s pid %d\n",
> file_priv->ctx.id, current->comm, task_pid_nr(current));
>
> + if (pm_runtime_get_if_active(vdev->drm.dev) > 0) {
[Severity: High]
Does this skip the newly added job abort logic entirely when the kernel is
built without CONFIG_PM?
When CONFIG_PM is disabled, pm_runtime_get_if_active() returns -EINVAL.
This causes the condition to evaluate to false, completely bypassing the
context abort and job cleanup steps.
If an application submits jobs and closes the DRM file descriptor on a system
with CONFIG_PM=n, the driver silently skips this cleanup. This appears to
defeat the purpose of the patch on those systems, as in-flight jobs will
continue running in the background.
Could this be exploited by untrusted or unprivileged userspace to launch
long-running jobs and detach from them, causing resource exhaustion on the
NPU?
> + mutex_lock(&file_priv->lock);
> + if (file_priv->bound && !file_priv->aborted)
> + ivpu_context_abort_locked(file_priv);
> + mutex_unlock(&file_priv->lock);
> +
> + ivpu_context_abort_all_jobs(vdev, file_priv->ctx.id);
> +
> + ivpu_rpm_put(vdev);
> + }
> +
> ivpu_ms_cleanup(file_priv);
> ivpu_file_priv_put(&file_priv);
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260914082929.892437-1-karol.wachowski@linux.intel.com?part=1
next prev parent reply other threads:[~2026-09-14 8:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 8:29 [PATCH] accel/ivpu: Abort pending jobs on file close Karol Wachowski
2026-09-14 8:48 ` sashiko-bot [this message]
2026-10-02 16:52 ` Jeff Hugo
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=20260914084849.706A01F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=karol.wachowski@linux.intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.