[PATCH ath-next 0/4] wifi: ath: Don't use %pK through printk

Thomas Weißschuh posted 4 patches 8 months ago
drivers/net/wireless/ath/ath10k/ahb.c       |  2 +-
drivers/net/wireless/ath/ath10k/bmi.c       |  6 +++---
drivers/net/wireless/ath/ath10k/ce.c        |  4 ++--
drivers/net/wireless/ath/ath10k/core.c      |  4 ++--
drivers/net/wireless/ath/ath10k/htc.c       |  6 +++---
drivers/net/wireless/ath/ath10k/htt_rx.c    |  2 +-
drivers/net/wireless/ath/ath10k/mac.c       | 22 +++++++++++-----------
drivers/net/wireless/ath/ath10k/pci.c       |  2 +-
drivers/net/wireless/ath/ath10k/testmode.c  |  4 ++--
drivers/net/wireless/ath/ath10k/txrx.c      |  2 +-
drivers/net/wireless/ath/ath10k/usb.c       |  4 ++--
drivers/net/wireless/ath/ath10k/wmi.c       |  4 ++--
drivers/net/wireless/ath/ath11k/testmode.c  |  2 +-
drivers/net/wireless/ath/ath12k/testmode.c  |  4 ++--
drivers/net/wireless/ath/wcn36xx/testmode.c |  2 +-
15 files changed, 35 insertions(+), 35 deletions(-)
[PATCH ath-next 0/4] wifi: ath: Don't use %pK through printk
Posted by Thomas Weißschuh 8 months ago
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.

These patches were originally part of
https://lore.kernel.org/lkml/20250414-restricted-pointers-net-v1-0-12af0ce46cdd@linutronix.de/

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (4):
      wifi: ath10k: Don't use %pK through printk
      wifi: ath11k: Don't use %pK through printk
      wifi: ath12k: Don't use %pK through printk
      wifi: wcn36xx: Don't use %pK through printk

 drivers/net/wireless/ath/ath10k/ahb.c       |  2 +-
 drivers/net/wireless/ath/ath10k/bmi.c       |  6 +++---
 drivers/net/wireless/ath/ath10k/ce.c        |  4 ++--
 drivers/net/wireless/ath/ath10k/core.c      |  4 ++--
 drivers/net/wireless/ath/ath10k/htc.c       |  6 +++---
 drivers/net/wireless/ath/ath10k/htt_rx.c    |  2 +-
 drivers/net/wireless/ath/ath10k/mac.c       | 22 +++++++++++-----------
 drivers/net/wireless/ath/ath10k/pci.c       |  2 +-
 drivers/net/wireless/ath/ath10k/testmode.c  |  4 ++--
 drivers/net/wireless/ath/ath10k/txrx.c      |  2 +-
 drivers/net/wireless/ath/ath10k/usb.c       |  4 ++--
 drivers/net/wireless/ath/ath10k/wmi.c       |  4 ++--
 drivers/net/wireless/ath/ath11k/testmode.c  |  2 +-
 drivers/net/wireless/ath/ath12k/testmode.c  |  4 ++--
 drivers/net/wireless/ath/wcn36xx/testmode.c |  2 +-
 15 files changed, 35 insertions(+), 35 deletions(-)
---
base-commit: cfb2e2c57aef75a414c0f18445c7441df5bc13be
change-id: 20250417-restricted-pointers-ath-4f279530336d

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Re: [PATCH ath-next 0/4] wifi: ath: Don't use %pK through printk
Posted by Jeff Johnson 8 months ago
On Thu, 17 Apr 2025 15:19:06 +0200, Thomas Weißschuh wrote:
> In the past %pK was preferable to %p as it would not leak raw pointer
> values into the kernel log.
> Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
> the regular %p has been improved to avoid this issue.
> Furthermore, restricted pointers ("%pK") were never meant to be used
> through printk(). They can still unintentionally leak raw pointers or
> acquire sleeping locks in atomic contexts.
> 
> [...]

Applied, thanks!

[1/4] wifi: ath10k: Don't use %pK through printk
      commit: 8add2b8d72722b60c749b559db2a2aef6c9def68
[2/4] wifi: ath11k: Don't use %pK through printk
      commit: 27c57c84922ef1dc72a2ea3a5427cdbaadc9be44
[3/4] wifi: ath12k: Don't use %pK through printk
      commit: 7e7f948c7d14ab5a6cfb26146a0d4734781903e3
[4/4] wifi: wcn36xx: Don't use %pK through printk
      commit: 75f90ba47b2cda7de7a7bc1d099172516f6f96fa

Best regards,
-- 
Jeff Johnson <jeff.johnson@oss.qualcomm.com>