From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fllvem-ot03.ext.ti.com (fllvem-ot03.ext.ti.com [198.47.19.245]) (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 CBA8145C0B for ; Wed, 13 Aug 2025 14:31:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.19.245 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755095521; cv=none; b=ahSXQFBCRCvk95CuV4VEyhBG5kQk7caDeTe1QftFWPQe1viX/EjfwmHGHdGokp/MIVzdFKyci+6pkm6DRjF6qPvC7YMI0DVFn16s4T+dFiLi9932N0nA6OfbmpbExwD6euj0Sp1Od1vERGyxe76Jr5JWSlhNdvP3tz7f396kQzw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755095521; c=relaxed/simple; bh=/9OUuDmY3Spspt7xwAHjvszbHzPjrxr1ZpiymLMoAhI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SdW1RxuwNpQBr9p+MjAvdk0gnphy3n3JtBBKDKeY3NUUeAiFU+49PCuRDGHX5YTVo1DyT6559goN9XZkcWW9ylcawomwdKe7TK69bJktLtu8mXb8YRclL7eB0tkeyYNU8+xEJrfbpCPgtfRFytPIaSd1MAK34FtjBH2qNc/MQ7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=hmEMQZUT; arc=none smtp.client-ip=198.47.19.245 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="hmEMQZUT" Received: from lelvem-sh02.itg.ti.com ([10.180.78.226]) by fllvem-ot03.ext.ti.com (8.15.2/8.15.2) with ESMTP id 57DEVdDU1666826; Wed, 13 Aug 2025 09:31:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1755095499; bh=SJZXS5Y9aHrIczypKO6ef3Wj3AFrPGLvZe4rLGJS3xk=; h=From:To:CC:Subject:Date:In-Reply-To:References; b=hmEMQZUTT/pXyUFwBoyXlc4tJ48HL8cxn8e7BBGxI+xqNdD2l/hqey9hBgBwSSuq9 2WpYoSEpuagwD0P4c8Nr/naQigy7Qign6Dm2aqQtm8YsQNm3GxHze/61uEz7g945M+ 3N8sakLTAXiPBvdYaUCsrB8wHwT79+Et3Sw8I380= Received: from DLEE105.ent.ti.com (dlee105.ent.ti.com [157.170.170.35]) by lelvem-sh02.itg.ti.com (8.18.1/8.18.1) with ESMTPS id 57DEVdW81036454 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=FAIL); Wed, 13 Aug 2025 09:31:39 -0500 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.55; Wed, 13 Aug 2025 09:31:38 -0500 Received: from lelvem-mr06.itg.ti.com (10.180.75.8) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.55 via Frontend Transport; Wed, 13 Aug 2025 09:31:38 -0500 Received: from localhost (uda0133052.dhcp.ti.com [128.247.81.232]) by lelvem-mr06.itg.ti.com (8.18.1/8.18.1) with ESMTP id 57DEVcTu2133995; Wed, 13 Aug 2025 09:31:38 -0500 From: Nishanth Menon To: Santosh Shilimkar , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= CC: Nishanth Menon , , Subject: Re: [PATCH v2] soc: ti: pruss: don't use %pK through printk Date: Wed, 13 Aug 2025 09:31:36 -0500 Message-ID: <175509547996.156478.5117406591592033849.b4-ty@ti.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250811-restricted-pointers-soc-v2-1-7af7ed993546@linutronix.de> References: <20250811-restricted-pointers-soc-v2-1-7af7ed993546@linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea Hi Thomas Weißschuh, On Mon, 11 Aug 2025 09:48:30 +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. > > [...] I have applied the following to branch ti-drivers-soc-next on [1]. Thank you! [1/1] soc: ti: pruss: don't use %pK through printk commit: a5039648f86424885aae37f03dc39bc9cb972ecb All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent up the chain during the next merge window (or sooner if it is a relevant 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. [1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D https://ti.com/opensource