[PATCH] dmaengine: at_xdmac: Fixed printk format specifier when printing driver information.

[PATCH] dmaengine: at_xdmac: Fixed printk format specifier when printing driver information.

[Alexander Shiyan]

Use the correct printk specifier to print the address, otherwise
you get weird information:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0x(ptrval)
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0x(ptrval)

After the change, the information looks much more informative:
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xc8892000
at_xdmac f0004000.dma-controller: 16 channels, mapped at 0xc8894000

Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
---
 drivers/dma/at_xdmac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index ba25c23164e7..a4188046804d 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -2409,7 +2409,7 @@ static int at_xdmac_probe(struct platform_device *pdev)
 		goto err_dma_unregister;
 	}
 
-	dev_info(&pdev->dev, "%d channels, mapped at 0x%p\n",
+	dev_info(&pdev->dev, "%d channels, mapped at 0x%px\n",
 		 nr_channels, atxdmac->regs);
 
 	at_xdmac_axi_config(pdev);
-- 
2.39.1

Re: [PATCH] dmaengine: at_xdmac: Fixed printk format specifier when printing driver information.

[Nathan Lynch]

Hi Alexander,

Alexander Shiyan <eagle.alexander923@gmail.com> writes:
> Use the correct printk specifier to print the address, otherwise
> you get weird information:
> at_xdmac f0010000.dma-controller: 16 channels, mapped at 0x(ptrval)
> at_xdmac f0004000.dma-controller: 16 channels, mapped at 0x(ptrval)
>
> After the change, the information looks much more informative:
> at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xc8892000
> at_xdmac f0004000.dma-controller: 16 channels, mapped at 0xc8894000
>
...
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -2409,7 +2409,7 @@ static int at_xdmac_probe(struct platform_device *pdev)
>  		goto err_dma_unregister;
>  	}
>  
> -	dev_info(&pdev->dev, "%d channels, mapped at 0x%p\n",
> +	dev_info(&pdev->dev, "%d channels, mapped at 0x%px\n",
>  		 nr_channels, atxdmac->regs);

dev_info (i.e. printk) obfuscates kernel pointers by design. This change
would defeat that.

Please refer to the discussion of pointers in
Documentation/core-api/printk-formats.rst for an explanation of the
"(ptrval)" behavior and whether it's appropriate to use %px here:

  Before using %px, consider if using %p is sufficient together with
  enabling the 'no_hash_pointers' kernel parameter during debugging
  sessions.

As well as related discussion in Documentation/process/deprecated.rst:

  %p format specifier
  -------------------
  Traditionally, using "%p" in format strings would lead to regular address
  exposure flaws in dmesg, proc, sysfs, etc. Instead of leaving these to
  be exploitable, all "%p" uses in the kernel are being printed as a hashed
  value, rendering them unusable for addressing. New uses of "%p" should not
  be added to the kernel. For text addresses, using "%pS" is likely better,
  as it produces the more useful symbol name instead. For nearly everything
  else, just do not add "%p" at all.