linux-kernel - [PATCH] x86/ioremap: Always incriminate the caller on failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 15 Feb 2022 14:07:21 +0000
From:   Chris Down <chris@...isdown.name>
To:     linux-kernel@...r.kernel.org
Cc:     x86@...nel.org
Subject: [PATCH] x86/ioremap: Always incriminate the caller on failure

On my T14s Gen2, I get the following on startup:

    e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
    e1000e 0000:00:1f.6 eth0: MAC: 14, PHY: 12, PBA No: FFFFFF-0FF
    sof-audio-pci-intel-tgl 0000:00:1f.3: warn: FW ABI is more recent than kernel
    ioremap error for 0x930bc000-0x930bd000, requested 0x2, got 0x0
    sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
    ucsi_acpi: probe of USBC000:00 failed with error -12

Notice the ioremap error which appears sandwiched between SOF driver
messages. Without more knowledge of the kernel, and due to the
interleaving of printk errors, it's not immediately obvious to the
system administrator where this message comes from (although in this
case tracing confirms that it comes from ucsi_acpi's ->probe, as one
might expect).

To avoid issues with printk interleaving, always incriminate the caller
on ioremap() failure since we have it. While we're here, also change
these from printk(KERN_FOO) to pr_foo(), which we already use elsewhere
in ioremap.c

Signed-off-by: Chris Down <chris@...isdown.name>
---
 arch/x86/mm/ioremap.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 026031b3b782..4051094e614b 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -195,8 +195,8 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 		return NULL;
 
 	if (!phys_addr_valid(phys_addr)) {
-		printk(KERN_WARNING "ioremap: invalid physical address %llx\n",
-		       (unsigned long long)phys_addr);
+		pr_warn("%pS: ioremap: invalid physical address %llx\n",
+			caller, (unsigned long long)phys_addr);
 		WARN_ON_ONCE(1);
 		return NULL;
 	}
@@ -207,8 +207,8 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 	 * Don't allow anybody to remap normal RAM that we're using..
 	 */
 	if (io_desc.flags & IORES_MAP_SYSTEM_RAM) {
-		WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
-			  &phys_addr, &last_addr);
+		WARN_ONCE(1, "%pS: ioremap on RAM at %pa - %pa\n",
+			  caller, &phys_addr, &last_addr);
 		return NULL;
 	}
 
@@ -222,14 +222,15 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 	retval = memtype_reserve(phys_addr, (u64)phys_addr + size,
 						pcm, &new_pcm);
 	if (retval) {
-		printk(KERN_ERR "ioremap memtype_reserve failed %d\n", retval);
+		pr_err("%pS: ioremap memtype_reserve failed %d\n",
+		       caller, retval);
 		return NULL;
 	}
 
 	if (pcm != new_pcm) {
 		if (!is_new_memtype_allowed(phys_addr, size, pcm, new_pcm)) {
-			printk(KERN_ERR
-		"ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
+			pr_err("%pS: ioremap error for 0x%llx-0x%llx, requested 0x%x, got 0x%x\n",
+				caller,
 				(unsigned long long)phys_addr,
 				(unsigned long long)(phys_addr + size),
 				pcm, new_pcm);
@@ -292,7 +293,7 @@ __ioremap_caller(resource_size_t phys_addr, unsigned long size,
 	 * tree.
 	 */
 	if (iomem_map_sanity_check(unaligned_phys_addr, unaligned_size))
-		pr_warn("caller %pS mapping multiple BARs\n", caller);
+		pr_warn("%pS: mapping multiple BARs\n", caller);
 
 	return ret_addr;
 err_free_area:
-- 
2.34.1