All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Marek Czernohous" <mczernohous@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 3/3] drm/nouveau/fifo: add recovery path for Tesla cache_error/dma_pusher
Date: Thu, 06 Aug 2026 09:29:28 +0000	[thread overview]
Message-ID: <20260806092928.AF7DF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806085228.1848994-4-mczernohous@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Race condition between nvkm_chan_del() and nv04_fifo_recover() leaves a dangling pointer in wedge.chfault, allowing a newly allocated channel to incorrectly inherit a fault streak.
--

--- Patch [3]: [PATCH v2 3/3] drm/nouveau/fifo: add recovery path for Tesla cache_error/dma_pusher ---
commit 673f2147a13507bd6f62792657604b061ac497d7
Author: Marek Czernohous <marek@czernohous.de>

drm/nouveau/fifo: add recovery path for Tesla cache_error/dma_pusher

This commit adds a shared recovery helper, nv04_fifo_recover, for Tesla
chipset FIFO fault handling. It implements a two-tier recovery mechanism
that kills channels after a burst of faults and requests a device-wide
wedge event if faults continue.

> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c
> index 418a8918bcb8f..79774c6460f4f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c

[ ... ]

> @@ -275,6 +275,20 @@ nvkm_chan_del(struct nvkm_chan **pchan)
>  	nvkm_gpuobj_del(&chan->ramfc);
>  
>  	if (chan->cgrp) {
> +		struct nvkm_fifo *fifo = chan->cgrp->runl->fifo;
> +
> +		/* Drop this channel's fault streak before the id is reused. */
> +		if (chan->id >= 0) {
> +			typeof(&fifo->wedge.chfault[0]) cf =
> +				&fifo->wedge.chfault[chan->id % NVKM_FIFO_KILL_CHID_MAX];
> +			unsigned long flags;
> +
> +			spin_lock_irqsave(&fifo->wedge.lock, flags);
> +			if (cf->owner == chan)
> +				cf->owner = NULL;
> +			spin_unlock_irqrestore(&fifo->wedge.lock, flags);

[Severity: Medium]
Can a concurrent nv04_fifo_recover() race with this teardown and leave a
dangling pointer in cf->owner?

Because this is cleared before nvkm_chid_put() unlinks the channel, and
before chan->cgrp->lock is acquired, is it possible for the following
sequence to occur:

CPU1 in nvkm_chan_del():
    spin_lock_irqsave(&fifo->wedge.lock, flags);
    if (cf->owner == chan)
        cf->owner = NULL;
    spin_unlock_irqrestore(&fifo->wedge.lock, flags);

CPU2 handling an interrupt in nv04_fifo_recover():
    chan = nvkm_chan_get_chid(...) 
    ...
    spin_lock_irqsave(&w->lock, wflags);
    if (cf->owner != chan || ...) {
        cf->owner = chan;
    }

CPU1 then calls nvkm_chid_put() unlinking the channel, and it is freed.

Would this leave the freed memory address in cf->owner, causing a newly
allocated channel that happens to reuse this address to incorrectly inherit
the previous channel's fault streak?

> +		}
> +
>  		nvkm_chid_put(chan->cgrp->runl->chid, chan->id, &chan->cgrp->lock);
>  		nvkm_cgrp_unref(&chan->cgrp);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806085228.1848994-1-mczernohous@gmail.com?part=3

  reply	other threads:[~2026-08-06  9:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06  8:52 [PATCH v2 0/3] drm/nouveau: nv04 FIFO cleanup + recovery for Tesla Marek Czernohous
2026-08-06  8:52 ` Marek Czernohous
2026-08-06  8:52 ` [PATCH v2 1/3] drm/nouveau/fifo/nv04: filter benign CACHE_ERROR from Mesa NV50 bind probe Marek Czernohous
2026-08-06  8:52   ` Marek Czernohous
2026-08-06  8:52 ` [PATCH v2 2/3] drm/nouveau: subscribe to channel-kill events on NV50 and newer Marek Czernohous
2026-08-06  8:52   ` Marek Czernohous
2026-08-06  9:20   ` sashiko-bot
2026-08-06  8:52 ` [PATCH v2 3/3] drm/nouveau/fifo: add recovery path for Tesla cache_error/dma_pusher Marek Czernohous
2026-08-06  8:52   ` Marek Czernohous
2026-08-06  9:29   ` sashiko-bot [this message]
2026-08-06  9:59 ` [PATCH v2 0/3] drm/nouveau: nv04 FIFO cleanup + recovery for Tesla Marek Czernohous
2026-08-06  9:59   ` Marek Czernohous

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=20260806092928.AF7DF1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mczernohous@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.