From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CD683A169F; Mon, 29 Jun 2026 06:59:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782716397; cv=none; b=k37TqD1xDSJKzb5NDqS4JIK8FSwleDFzJOQaya8ryg/E/BvEpvi5CFqlbFohCSjoIfb2PJa9dPDTYCWG7orJmwnZjJdnFBUiZHUk3lAVU49sMg2NTOHp4M8GW8A07FM5MvHeL7q7bIXgHaRyUFKBsuFtzJ72diTNTOF3C9RHuFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782716397; c=relaxed/simple; bh=cfj6qsLX7lbSG0og6v/xy08fwwUJ7Cuhaei+hCrYdR0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=odXrXz7z5gqpjeZRmF55fuaEW+pP7Wig98LoXz65/3MT7DA886AepkvbnTfAC8KReHHyzGQD+VP6zl0I+YOyFoUgMvxXlp62yQXkJ+PxgdhsR6aUQA1lKNmRnimlOkCBKVbhEHe7VvqfZkvAw1K3i8NsfxIZ2EGXFpEk/DadMYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=OpZpETnl; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="OpZpETnl" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4gpcbW4kVfz9tv4; Mon, 29 Jun 2026 08:59:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1782716391; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3hbzEnZLAxVe7ov2oMC76sAGhhFWZLnsRyY/MSpvDoM=; b=OpZpETnl2QbkF2dT5mnB5Yni7iy5P50niEkB/W2TSRxOOM32j7izTnQjyiENXcbK26PltS v3NslQjcrwoKez3ZUrZeKNsdYHpJHIyjJ/W/Yo0Bmqa5kWhPS3uachHQX+TLXQMJ4mLHI9 Nm6hQ4d3/UPJEIxR56wmEXB4WubGN9NYpyDKIQq6m5x28UeyHv2dLCXaiKWeywrWktbL5K OQOuuge2wOLZ9QiSbbvZ2p3dfhWJDa7/lqSexq1rdxFq1+2mt40I5JgScnzON9FQ1TLjxb qiTOtHvA+Jgak4v64ATZwUhVlPVFSugA0cHre/RSPjKxRu3SQNTIjPILaeL/BA== Message-ID: Subject: Re: [PATCH] dma-fence: Make dma_fence_dedup_array() robust against 0-count input From: Philipp Stanner Reply-To: phasta@kernel.org To: Baineng Shou , Sumit Semwal , Christian =?ISO-8859-1?Q?K=F6nig?= Cc: Tvrtko Ursulin , Philipp Stanner , Akash Goel , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Date: Mon, 29 Jun 2026 08:59:47 +0200 In-Reply-To: <20260629031346.3875683-1-shoubaineng@gmail.com> References: <20260629031346.3875683-1-shoubaineng@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MBO-RS-META: bbk6f6twdq8kmn36mzidwpfnhkk5qc61 X-MBO-RS-ID: 236d4085a3bc31e8aaf On Mon, 2026-06-29 at 11:13 +0800, Baineng Shou wrote: > dma_fence_dedup_array() returns 1 when called with num_fences =3D=3D 0: > the for-loop body never executes, j stays at 0, and the final > `return ++j` yields 1. This contradicts both the kernel-doc ("Return: > Number of unique fences remaining in the array") and the natural > expectation that 0 input gives 0 output. >=20 > All in-tree callers currently filter num_fences =3D=3D 0 before invoking > this helper (__dma_fence_unwrap_merge() bails out via the > `if (count =3D=3D 0 || count =3D=3D 1)` fast path; amdgpu_userq_wait_*() > cannot reach the dedup call with a zero local count because the > amdgpu_userq_wait_add_fence() helper guarantees num_fences stays in > [0, wait_info->num_fences], and wait_info->num_fences > 0 is enforced > at the ioctl entry). >=20 > However, dma_fence_dedup_array() is EXPORT_SYMBOL_GPL, so any future > caller that forgets to pre-filter the zero case will get a misleading > return value of 1. Depending on how that caller uses the result, it > could dereference an uninitialized fence slot in the array, since the > caller's array may have been allocated but not yet populated. >=20 > Make the contract match the documentation by returning 0 early. This > also skips an unnecessary sort() call on an empty array. >=20 > Signed-off-by: Baineng Shou > --- > =C2=A0drivers/dma-buf/dma-fence-unwrap.c | 3 +++ > =C2=A01 file changed, 3 insertions(+) >=20 > diff --git a/drivers/dma-buf/dma-fence-unwrap.c b/drivers/dma-buf/dma-fen= ce-unwrap.c > index 53bb40e70b27..364cbf79ad73 100644 > --- a/drivers/dma-buf/dma-fence-unwrap.c > +++ b/drivers/dma-buf/dma-fence-unwrap.c > @@ -97,6 +97,9 @@ int dma_fence_dedup_array(struct dma_fence **fences, in= t num_fences) > =C2=A0{ > =C2=A0 int i, j; > =C2=A0 > + if (!num_fences) > + return 0; Hm, since you're adding this, what about num_fences =3D -5 ? Let me use this opportunity to also highlight that we should, in C, in general get away from using int for everything. __dma_fence_unwrap_merge() directly below uses unsigned int, as you would expect. dma_fence_dedup_array() has almost no users. Probably we should change that API to unsigned int, too? Regards P. > + > =C2=A0 sort(fences, num_fences, sizeof(*fences), fence_cmp, NULL); > =C2=A0 > =C2=A0 /*