From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DC8630AAD0; Wed, 3 Dec 2025 15:32:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764775959; cv=none; b=IcH+yM/oGPfNvx5JY89+9KblMxR3OtYx4DMD3ZfPmORY9sFW1zzgrcQCKwQXkSJYCciHLUQjLb3prSZJoCWqzt/yqW2kYwTJRDm4jZP5k62FlJhunhR2+ZOi4QwqZAztjjwnWHHX1ZHp0cDLpkUbuYRju6dc+WwoT7ccjH3dK4U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764775959; c=relaxed/simple; bh=1XkozQCqFZ71/dx3RlzoWLm3Hpu1EMwQWR9ugXAqScs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cNWjRaBQ7yNVKgBw26wTbD7i4g7/LiUuUMoM8J0k/bMZkHN7IxC4BvqmPG8gOhhev1OAPNUg1NZOnkYsXEzqEUDesJkGLVT7Da9I5xhpF2bVsvPJb20sBm0CDo7Nwpr3KnLzcjdZFGtxSGCfKOm1j27BuDd5kxd0ILnAMQJN9Sw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=blFcxQDc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="blFcxQDc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26CDCC116B1; Wed, 3 Dec 2025 15:32:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764775958; bh=1XkozQCqFZ71/dx3RlzoWLm3Hpu1EMwQWR9ugXAqScs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=blFcxQDcXSiJsnHOX42VT2DwEpoaih5jckaeUeLAj1FNLqsuntLzIqPa29Ft+MQse m1G+s6F3RvmEp0vxCiVcsB0SHZII76BxNz4/jyR3Xgb4ySfAIPPdYaw45yn/X42vNX OnbyCESkQopomjgFBYHDLCvzTlJnEDRW7R/aAAq0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= , Mark Brown , Sasha Levin Subject: [PATCH 5.10 039/300] spi: loopback-test: Dont use %pK through printk Date: Wed, 3 Dec 2025 16:24:03 +0100 Message-ID: <20251203152402.057690369@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251203152400.447697997@linuxfoundation.org> References: <20251203152400.447697997@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Thomas Weißschuh [ Upstream commit b832b19318534bb4f1673b24d78037fee339c679 ] 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. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh Link: https://patch.msgid.link/20250811-restricted-pointers-spi-v1-1-32c47f954e4d@linutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- drivers/spi/spi-loopback-test.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c index 89fccb9da1b8e..556118c931092 100644 --- a/drivers/spi/spi-loopback-test.c +++ b/drivers/spi/spi-loopback-test.c @@ -409,7 +409,7 @@ static void spi_test_dump_message(struct spi_device *spi, int i; u8 b; - dev_info(&spi->dev, " spi_msg@%pK\n", msg); + dev_info(&spi->dev, " spi_msg@%p\n", msg); if (msg->status) dev_info(&spi->dev, " status: %i\n", msg->status); @@ -419,15 +419,15 @@ static void spi_test_dump_message(struct spi_device *spi, msg->actual_length); list_for_each_entry(xfer, &msg->transfers, transfer_list) { - dev_info(&spi->dev, " spi_transfer@%pK\n", xfer); + dev_info(&spi->dev, " spi_transfer@%p\n", xfer); dev_info(&spi->dev, " len: %i\n", xfer->len); - dev_info(&spi->dev, " tx_buf: %pK\n", xfer->tx_buf); + dev_info(&spi->dev, " tx_buf: %p\n", xfer->tx_buf); if (dump_data && xfer->tx_buf) spi_test_print_hex_dump(" TX: ", xfer->tx_buf, xfer->len); - dev_info(&spi->dev, " rx_buf: %pK\n", xfer->rx_buf); + dev_info(&spi->dev, " rx_buf: %p\n", xfer->rx_buf); if (dump_data && xfer->rx_buf) spi_test_print_hex_dump(" RX: ", xfer->rx_buf, @@ -521,7 +521,7 @@ static int spi_check_rx_ranges(struct spi_device *spi, /* if still not found then something has modified too much */ /* we could list the "closest" transfer here... */ dev_err(&spi->dev, - "loopback strangeness - rx changed outside of allowed range at: %pK\n", + "loopback strangeness - rx changed outside of allowed range at: %p\n", addr); /* do not return, only set ret, * so that we list all addresses @@ -659,7 +659,7 @@ static int spi_test_translate(struct spi_device *spi, } dev_err(&spi->dev, - "PointerRange [%pK:%pK[ not in range [%pK:%pK[ or [%pK:%pK[\n", + "PointerRange [%p:%p[ not in range [%p:%p[ or [%p:%p[\n", *ptr, *ptr + len, RX(0), RX(SPI_TEST_MAX_SIZE), TX(0), TX(SPI_TEST_MAX_SIZE)); -- 2.51.0