[PATCH] gpu/drm/nouveau: fix return type in nouveau_dmem_migrate_to_ram()

Balbir Singh posted 1 patch 2 months, 3 weeks ago
drivers/gpu/drm/nouveau/nouveau_dmem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
[PATCH] gpu/drm/nouveau: fix return type in nouveau_dmem_migrate_to_ram()
Posted by Balbir Singh 2 months, 3 weeks ago
ret of type vm_fault_t is reused to capture the return value of
nouveau_dmem_copy_folio(), which returns an int. Use a new variable
err to fix the issue. The issue is not new, prior to this the function
called was called nouveau_dmem_copy_one() and ret was used to capture
it's value.

The bug does not cause a real issue at runtime, the value is used
as a boolean to check if nouveau_dmem_copy_folio() succeeded or failed.
The different types should not impact the execution of the code at
runtime.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511121922.oP20Lzb8-lkp@intel.com/

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: Rakie Kim <rakie.kim@sk.com>
Cc: Byungchul Park <byungchul@sk.com>
Cc: Gregory Price <gourry@gourry.net>
Cc: Ying Huang <ying.huang@linux.alibaba.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Nico Pache <npache@redhat.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Barry Song <baohua@kernel.org>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Mika Penttilä <mpenttil@redhat.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>

Signed-off-by: Balbir Singh <balbirs@nvidia.com>
---
 drivers/gpu/drm/nouveau/nouveau_dmem.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 244812e7dd69..58071652679d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -188,6 +188,7 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct vm_fault *vmf)
 	struct nouveau_svmm *svmm;
 	struct page *dpage;
 	vm_fault_t ret = 0;
+	int err;
 	struct migrate_vma args = {
 		.vma		= vmf->vma,
 		.pgmap_owner	= drm->dev,
@@ -256,9 +257,9 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct vm_fault *vmf)
 	svmm = folio_zone_device_data(sfolio);
 	mutex_lock(&svmm->mutex);
 	nouveau_svmm_invalidate(svmm, args.start, args.end);
-	ret = nouveau_dmem_copy_folio(drm, sfolio, dfolio, &dma_info);
+	err = nouveau_dmem_copy_folio(drm, sfolio, dfolio, &dma_info);
 	mutex_unlock(&svmm->mutex);
-	if (ret) {
+	if (err) {
 		ret = VM_FAULT_SIGBUS;
 		goto done;
 	}
-- 
2.51.1

Re: [PATCH] gpu/drm/nouveau: fix return type in nouveau_dmem_migrate_to_ram()
Posted by David Hildenbrand (Red Hat) 2 months, 3 weeks ago
On 14.11.25 02:22, Balbir Singh wrote:
> ret of type vm_fault_t is reused to capture the return value of
> nouveau_dmem_copy_folio(), which returns an int. Use a new variable
> err to fix the issue. The issue is not new, prior to this the function
> called was called nouveau_dmem_copy_one() and ret was used to capture
> it's value.
> 
> The bug does not cause a real issue at runtime, the value is used
> as a boolean to check if nouveau_dmem_copy_folio() succeeded or failed.
> The different types should not impact the execution of the code at
> runtime.
> 

Also, as commented previously, the prefix in the subject does not match 
existing norms. Take a look at

	git log --oneline drivers/gpu/drm/nouveau/nouveau_dmem.c

and note how it's commonly something along the lines of "drm/nouveau" or 
better "drm/nouveau/dmem".

The only patch that uses "gpu/drm/nouveau" is from you recently. In 
fact, there is no other patch in the codebase that uses that prefix.

-- 
Cheers

David
Re: [PATCH] gpu/drm/nouveau: fix return type in nouveau_dmem_migrate_to_ram()
Posted by Balbir Singh 2 months, 3 weeks ago
On 11/14/25 19:33, David Hildenbrand (Red Hat) wrote:
> On 14.11.25 02:22, Balbir Singh wrote:
>> ret of type vm_fault_t is reused to capture the return value of
>> nouveau_dmem_copy_folio(), which returns an int. Use a new variable
>> err to fix the issue. The issue is not new, prior to this the function
>> called was called nouveau_dmem_copy_one() and ret was used to capture
>> it's value.
>>
>> The bug does not cause a real issue at runtime, the value is used
>> as a boolean to check if nouveau_dmem_copy_folio() succeeded or failed.
>> The different types should not impact the execution of the code at
>> runtime.
>>
> 
> Also, as commented previously, the prefix in the subject does not match existing norms. Take a look at
> 
>     git log --oneline drivers/gpu/drm/nouveau/nouveau_dmem.c
> 
> and note how it's commonly something along the lines of "drm/nouveau" or better "drm/nouveau/dmem".
> 
> The only patch that uses "gpu/drm/nouveau" is from you recently. In fact, there is no other patch in the codebase that uses that prefix.
> 

I'll fix the subject prefix

Thanks for the review,
Balbir
Re: [PATCH] gpu/drm/nouveau: fix return type in nouveau_dmem_migrate_to_ram()
Posted by David Hildenbrand (Red Hat) 2 months, 3 weeks ago
On 14.11.25 02:22, Balbir Singh wrote:
> ret of type vm_fault_t is reused to capture the return value of
> nouveau_dmem_copy_folio(), which returns an int. Use a new variable
> err to fix the issue. The issue is not new, prior to this the function
> called was called nouveau_dmem_copy_one() and ret was used to capture
> it's value.
> 
> The bug does not cause a real issue at runtime, the value is used
> as a boolean to check if nouveau_dmem_copy_folio() succeeded or failed.
> The different types should not impact the execution of the code at
> runtime.

Again, spell out that it is a sparse warning one way or the other and 
ideally paste the relevant part here,

Also, take a look at the definition of "bug", like at wikipedia

"In engineering, a bug is a design defect in an engineered system—such 
as software, computer hardware, electronics, circuitry or machinery—that 
causes an undesired result."

Talking about a bug when nothing is broken can be really misleading to 
people that watch out for CVEs etc.

-- 
Cheers

David