| Message ID | 20250328105654.143676-1-eagle.alexander923@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | dmaengine: at_xdmac: Fixed printk format specifier when printing driver information. | expand |
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.
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);
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(-)