ASoC: wm_adsp: Don't use no_free_ptr() when passing to PTR_ERR()

[PATCH] ASoC: wm_adsp: Don't use no_free_ptr() when passing to PTR_ERR()

Posted by Richard Fitzgerald 9 months, 2 weeks ago

It's no longer necessary to no_free_ptr() an auto-freed pointer before
passing it to PTR_ERR(). This was fixed by commit
cd7eb8f83fcf ("mm/slab: make __free(kfree) accept error pointers").

Removing the no_free_ptr() avoids the spurious warning
"inconsistent IS_ERR and PTR_ERR".

Fixes: b5d057a86e20 ("ASoC: wm_adsp: Use vmemdup_user() instead of open-coding")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202504270751.nR3Ngfrq-lkp@intel.com/
---
 sound/soc/codecs/wm_adsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index a2e9f32209cf..e822979e6a19 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -419,7 +419,7 @@ static int wm_coeff_tlv_put(struct snd_kcontrol *kctl,
 	void *scratch __free(kvfree) = vmemdup_user(bytes, size);
 
 	if (IS_ERR(scratch))
-		return PTR_ERR(no_free_ptr(scratch));
+		return PTR_ERR(scratch);
 
 	return cs_dsp_coeff_lock_and_write_ctrl(cs_ctl, 0, scratch, size);
 }
-- 
2.43.0

Re: [PATCH] ASoC: wm_adsp: Don't use no_free_ptr() when passing to PTR_ERR()

Posted by Mark Brown 9 months, 1 week ago

On Mon, 28 Apr 2025 10:08:03 +0100, Richard Fitzgerald wrote:
> It's no longer necessary to no_free_ptr() an auto-freed pointer before
> passing it to PTR_ERR(). This was fixed by commit
> cd7eb8f83fcf ("mm/slab: make __free(kfree) accept error pointers").
> 
> Removing the no_free_ptr() avoids the spurious warning
> "inconsistent IS_ERR and PTR_ERR".
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: wm_adsp: Don't use no_free_ptr() when passing to PTR_ERR()
      commit: 94602d84163c127ec2374fba0fcb6587a07785ce

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark