linux-kernel - Re: [PATCH] mmc: pxamci: Fix passing NULL to PTR_ERR() in pxamci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251009152744.9734-1-rakuram.e96@gmail.com>
Date: Thu,  9 Oct 2025 20:57:38 +0530
From: Rakuram Eswaran <rakuram.e96@...il.com>
To: u.kleine-koenig@...libre.com
Cc: chenhuacai@...nel.org,
	dan.carpenter@...aro.org,
	david.hunter.linux@...il.com,
	khalid@...nel.org,
	linux-kernel-mentees@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org,
	lkp@...el.com,
	rakuram.e96@...il.com,
	skhan@...uxfoundation.org,
	ulf.hansson@...aro.org,
	zhoubinbin@...ngson.cn
Subject: Re: [PATCH] mmc: pxamci: Fix passing NULL to PTR_ERR() in pxamci_probe() 

Hi Uwe,

Thanks a lot for the review and the clear explanation.

Your suggestion makes perfect sense — since host is devm-managed, 
explicitly assigning its members to NULL has no effect. 
I’ll remove those two redundant lines in v2 as you suggested.

I had one small clarification regarding the remaining host->dma_chan_tx = NULL;
in the TX DMA error path. Since that branch uses goto out, 
the cleanup section below may call dma_release_channel() on both RX 
and TX pointers. Setting TX to NULL there seems like a defensive step 
to avoid accidentally passing an ERR_PTR() to dma_release_channel() 
— is that understanding correct?

Also, I noticed that in the build configuration downloaded from the LKP report 
link (CONFIG_DMA_ENGINE isn’t defined), the kernel uses the stub inline 
version of dma_release_channel() from include/linux/dmaengine.h, 
which becomes a no-op. 

>From what I understand, when the DMA engine framework isn’t enabled, 
these APIs compile as no-ops through their inline stubs. 
Please correct me if I’m misunderstanding how this works.

Please let me know if this reasoning aligns with what you had in mind.

Thanks again for the insightful feedback — 
I’ll send v2 with those two cleanups shortly.

Best regards,
Rakuram