From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B0BC3932F7 for ; Wed, 10 Jun 2026 12:12:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781093548; cv=none; b=SdjYFVsTNDPT1Nn6qwqJ2IxYvkBuQSimFQpfTGxX4q1R2+5TH72XHZaNs1z0wo73eCKBZ8fc4e5piNZ7FzroKYs44d6XtCXl9asaSLsgqwTq7oF8AUAYxRNGismIrBA1IYZQxhfJ4E711SkoHQv0pF6R4ntyBdxZo7pc85c1/uU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781093548; c=relaxed/simple; bh=xKxml6eXRDHsraxuYzByMtlW+4xeMIj8kQS+dM67NiI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=H6Z0SW9xjIx07989WTy9ihkOIY36whgavwVnb2vyJvo4XzlwRLt0mwPZzEBvbtXhXwNuLxySyRDWvmHfUedtPmop0D05cLY0WMMKEk3HtfOyv3XJQUgk0iFmMZ8ihGA3B6ehg0jsnZ7MSKDLFsLesDVWP3ADYC9W1hjpQCHbYwI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net; spf=pass smtp.mailfrom=ursulin.net; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b=cAceAniF; arc=none smtp.client-ip=209.85.208.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ursulin.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b="cAceAniF" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-691c5776f95so5896608a12.3 for ; Wed, 10 Jun 2026 05:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ursulin.net; s=google; t=1781093545; x=1781698345; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YJe1xz1ZMNVnBlNAhTok//gR+6F59R46BnGd4lcF8bY=; b=cAceAniF11DkABv4isZHZvCfrwevBxHwmIJA5a0mL33/LvqTzQAZEbEzytAoueTmz2 FQpy67uhJjMjHEo7sMcYOQNm0hUvivHLRnT9chWEItYpn7zyPrBtvCWOVKzsXc+dnrGL MdO1ocQbTgFU11xsIIykeBeNFZ/lSMK5ttn82WZ+Gf+LO4Z9w9bNT4OD/focS67GeulY +p+iALdajotIXBzQ7Ul1vfC3c3Ee6ELeYbZFGsG03KYPHdw2iqg/cxoyrot/2sJYKE7y zs2SEW9amoDkO0brEDkEd4m1MN2tUyWzuLG87FrKtsehlNfE0LEJS3bOcrJW8JdzJovw mpAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781093545; x=1781698345; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YJe1xz1ZMNVnBlNAhTok//gR+6F59R46BnGd4lcF8bY=; b=OyrhvFI3heFeX7N74/v8aFpr12ZZqPYAvhoOwNfHbjWIzkbPoJz2+mmgp4NIwJhCcp UKBZ+7XPQd0u2tRnorr75cKfkfIyUNubVChxDmfPyWTRARmrh6hEitKC7VvPvrCVh1RV gilpWtBuP4X9udhkd4v/PikI7IAOAM4WLM4+GspBoUucNJNZWxg/LL8s4KM/C7EvGsUp mZSTkBJRiQ1gZS0pcaXlmUBrCyzXHwn+KglkGxpYZzJ/s7WV9hP9FiY3j4AFI8D2sj9f VIjYJ4GCYMD5BfV1DxOQ04vYVT4Z3936DpkDpwR3EzaKEc8t/mGS6fo6qnvgcdRHIRbX uzLw== X-Forwarded-Encrypted: i=1; AFNElJ+6mkxG/3UrngxuZg2mCSIoY0L8I3llGBeq/F7cfDjj3Hi/wtjX1C9OFrVuQWYc1JPYp2LkhJVs6RKA2vQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxYZ86u8me6//3KhJDAQ5tbWsWI1WXtgIYyOAnqxw+pdhVDwU/O K45v2eT2XFHM9t+jC6w/nM4Mpu73u382Upyyr+uIslN/oNJNCFHMUgPzEYj11w46CGE= X-Gm-Gg: Acq92OEp/3e15s+nR5ukAsQac7rWMaJugUULI5tDyYkFBwy8F5ViKxdCEzAUkVsQ70F SkyzYTRoIRvibAG3XfufAB7/LpOGGo3NE4fKjCHdAaP45j9UZYWdHa60TBsoaibg3Im9MFSjX88 1hNzvV8Az7talrrZMU2FVKYrd2qraWGV8OZNrb5Lhxa44qJondc3Gl3OMj/DkfFdac4NGcieYwC Yw1H8eKs0KnMYhXk6pVNEwJV61W5EYBrtyMgjh9B8QonVBj7fEWSAocFKTKPOydF1GJ8aLgsi3m g3sPRRhZlQdrD6LKuoe/FCqM95tIqJPrlYuS+f3AGagB9NQ3ErSH4DzNgSPVww0DXSWAZZ42PkI LbB5AdvkVfKfwY7VYnEGD+QkTd4avKh7Kt2nUTPdd0I2Dy1H9JMzcPJDs6vaWcYGGBHHpqR5X5R TiWOkkv/eUrXqDmqx6c99OZ6AzcSWlfaJz2Azq/DhDQPu+9njjPrnfvb2CvROfc2wbhw== X-Received: by 2002:a05:6402:5193:b0:66e:abe5:ab22 with SMTP id 4fb4d7f45d1cf-68fa4c0039fmr11944776a12.5.1781093544179; Wed, 10 Jun 2026 05:12:24 -0700 (PDT) Received: from [192.168.0.116] ([90.240.106.137]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-68e64e2c810sm9966710a12.9.2026.06.10.05.12.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2026 05:12:22 -0700 (PDT) Message-ID: Date: Wed, 10 Jun 2026 13:12:21 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] drm/nouveau: Document weird looking bugfix To: Philipp Stanner , Lyude Paul , Danilo Krummrich , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org References: <20260610082602.1292853-2-phasta@kernel.org> Content-Language: en-GB From: Tvrtko Ursulin In-Reply-To: <20260610082602.1292853-2-phasta@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/06/2026 09:26, Philipp Stanner wrote: > commit c8a5d5ea3ba6 ("nouveau: fix client work fence deletion race") > fixed a race. To do so, it replaced the automatically locking > dma_fence_is_signaled() with manual locks plus > dma_fence_is_signaled_locked(). > > For someone browsing through the code, this reads very much like a > cleanup or rework leftover. Future contributors and / or new maintainers > not familiar with the history might be tempted to remove that bugfix. > > Document the bugfix. > > Signed-off-by: Philipp Stanner > --- > (I did not test this) > --- > drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c > index 42a81166f3a9..519a0c164a72 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c > @@ -159,6 +159,13 @@ nouveau_cli_work_ready(struct dma_fence *fence) > unsigned long flags; > bool ret = true; > > + /* > + * This is not a cleanup / rework leftover, but a bugfix to prevent a > + * race with someone signalling the fence. The locked > + * dma_fence_is_signaled() cannot be used. The dma_fence implementation > + * is not fully synchronized with locks, but also uses atomic bits, > + * which can cause the dma_fence_put() below to be executed too soon. > + */ IMHO it would also be interesting to document why this happens from the nouveau point of view. For example I see the two references held on this fences in the call chain, but apparently neither are enough to close the race. Which suggests a third party has a pointer to this fence but with no reference. I talk about this: nouveau_gem_object_unmap -> nouveau_cli_work_queue There it grabs a reference before queing the worker. In the worker it drops it before calling the callback nouveau_gem_object_unmap installed: static void nouveau_cli_work(struct work_struct *w) { struct nouveau_cli *cli = container_of(w, typeof(*cli), work); struct nouveau_cli_work *work, *wtmp; mutex_lock(&cli->lock); list_for_each_entry_safe(work, wtmp, &cli->worker, head) { if (!work->fence || nouveau_cli_work_ready(work->fence)) { ... nouveau_cli_work_ready can drop one reference list_del(&work->head); work->func(work); ... then work->func was set to nouveau_gem_object_delete_work by nouveau_gem_object_unmap, which will end up calling: nouveau_gem_object_delete -> nouveau_fence_unref On possibly the same fence. So if there a path inside nouveau itself which signals the fence without holding a reference then could be it that the problem is self-inflicted and not due a dma-fence quirks? I am not entirely sure since it is not very clear. It needs someone with nouveau expertise to clarify. Regards, Tvrtko > dma_fence_lock_irqsave(fence, flags); > if (!dma_fence_is_signaled_locked(fence)) > ret = false;