All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Risto Pajula" <or.pajula@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/nouveau/fifo: use global nonstall event on legacy FIFO
Date: Sun, 13 Sep 2026 20:23:46 +0000	[thread overview]
Message-ID: <20260913202347.120A81F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260913201225.5975-3-or.pajula@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] If channel initialization fails early in `nvkm_chan_new_()`, the cleanup path dereferences a NULL `chan->cgrp`.
--

commit 6a368e9f19db8e6f77b9767f67dd0d51b8625cd8
Author: Risto Pajula <or.pajula@gmail.com>

drm/nouveau/fifo: use global nonstall event on legacy FIFO

This commit changes the nonstall event registration to use the runlist ID
only when per-runlist nonstall interrupts are supported, falling back to
event index 0 for legacy FIFO implementations. This fixes an issue where
fence completion waits for an event that is never signalled.

> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/uchan.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/uchan.c
> index d6a87cec21503..b96e841920320 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/uchan.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/uchan.c
> @@ -52,7 +52,8 @@ nvkm_uchan_uevent(struct nvkm_object *object, void *argv, u32 argc, struct nvkm_
>  
>  	switch (args->v0.type) {
>  	case NVIF_CHAN_EVENT_V0_NON_STALL_INTR:
> -		return nvkm_uevent_add(uevent, &runl->fifo->nonstall.event, runl->id,
> +		return nvkm_uevent_add(uevent, &runl->fifo->nonstall.event,
> +				runl->fifo->func->nonstall_ctor ? runl->id : 0,
>  				       NVKM_FIFO_NONSTALL_EVENT, NULL);
>  	case NVIF_CHAN_EVENT_V0_KILLED:
>  		return nvkm_uevent_add(uevent, &runl->chid->event, chan->id,

[Severity: Critical]
This is a pre-existing issue, but while reviewing the channel handling code, I
noticed a potential NULL pointer dereference if channel initialization fails
early.

In drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c:nvkm_chan_new_():

    ret = nvkm_cgrp_new(runl, chan->name, vmm, fifo->func->cgrp.force,
                        &chan->cgrp);
    if (ret) {
        RUNL_DEBUG(runl, "cgrp %d", ret);
        return ret;
    }

If nvkm_cgrp_new() fails, chan->cgrp remains NULL but the error is returned
to the caller while leaving the partially initialized channel allocated.

The cleanup path in nvkm_chan_del() unconditionally executes the RAMFC clear
callback on the partially initialized channel object:

drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c:nvkm_chan_del() {
    ...
    if (chan->func->ramfc->clear)
        chan->func->ramfc->clear(chan);
    ...
}

For hardware-specific implementations like nv04_chan_ramfc_clear() in
drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.c, this directly dereferences
chan->cgrp:

    struct nvkm_memory *ramfc =
        chan->cgrp->runl->fifo->engine.subdev.device->imem->ramfc;

Could this lead to a kernel panic when a userspace program invokes the
NVIF_IOCTL_NEW ioctl to create a new channel and nvkm_cgrp_new() fails? This
seems reachable if a user provides an invalid channel group or during memory
pressure.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913201225.5975-1-or.pajula@gmail.com?part=2

      reply	other threads:[~2026-09-13 20:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 20:12 [PATCH 0/2] drm/nouveau: fix GK107 VDPAU regressions Risto Pajula
2026-09-13 20:12 ` [PATCH 1/2] drm/nouveau/fifo/gk104: fix legacy video engine context mappings Risto Pajula
2026-09-13 20:12 ` [PATCH 2/2] drm/nouveau/fifo: use global nonstall event on legacy FIFO Risto Pajula
2026-09-13 20:23   ` sashiko-bot [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=20260913202347.120A81F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=or.pajula@gmail.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.