There are a number of places where early_ioremap is called
but the return pointer is not checked for NULL. The call
can result in a NULL being returned so the checks must
be added.
On allocation failures, panic() was used since this seemed
to be the action taken on other failures in the modules
touched by this patch.
Signed-off-by: Ross Philipson <[email protected]>
---
arch/x86/kernel/apic/x2apic_uv_x.c | 2 ++
arch/x86/kernel/early_printk.c | 2 ++
arch/x86/kernel/vsmp_64.c | 3 +++
3 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c
index 4828552..4ffdc27 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -75,6 +75,8 @@ static unsigned long __init uv_early_read_mmr(unsigned long addr)
unsigned long val, *mmr;
mmr = early_ioremap(UV_LOCAL_MMR_BASE | addr, sizeof(*mmr));
+ if (!mmr)
+ panic("UV: error: failed to ioremap MMR\n");
val = *mmr;
early_iounmap(mmr, sizeof(*mmr));
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 44f9370..1fe590d 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -290,6 +290,8 @@ static __init void early_pci_serial_init(char *s)
/* WARNING! assuming the address is always in the first 4G */
early_serial_base =
(unsigned long)early_ioremap(bar0 & PCI_BASE_ADDRESS_MEM_MASK, 0x10);
+ if (!early_serial_base)
+ panic("early_serial: failed to ioremap MMIO BAR\n");
write_pci_config(bus, slot, func, PCI_COMMAND,
cmdreg|PCI_COMMAND_MEMORY);
}
diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index 796cfaa..39769f4 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -32,6 +32,9 @@ static void __init set_vsmp_ctl(void)
/* set vSMP magic bits to indicate vSMP capable kernel */
cfg = read_pci_config(0, 0x1f, 0, PCI_BASE_ADDRESS_0);
address = early_ioremap(cfg, 8);
+ if (WARN_ON(!address))
+ return;
+
cap = readl(address);
ctl = readl(address + 4);
printk(KERN_INFO "vSMP CTL: capabilities:0x%08x control:0x%08x\n",
--
1.8.3.1
On Thu, Nov 10, 2022 at 03:45:21PM +0000, Ross Philipson wrote:
> On allocation failures, panic() was used since this seemed
> to be the action taken on other failures in the modules
> touched by this patch.
How is the panic() more useful than the obvious NULL deref that also
splats?
On 11/10/22 13:07, Peter Zijlstra wrote:
> On Thu, Nov 10, 2022 at 03:45:21PM +0000, Ross Philipson wrote:
>> On allocation failures, panic() was used since this seemed
>> to be the action taken on other failures in the modules
>> touched by this patch.
>
> How is the panic() more useful than the obvious NULL deref that also
> splats?
>
My answer here is basically the same as the answer in the reply to Dave
Hansen I sent a moment ago. I think one of the primary motivation was to
make things consistent.
Thanks
Ross