ERST: how to avoid a dynamic memory allocation in panic case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Issue]

Current erst driver is kicked in panic case.
On the other hand, a dynamic memory allocation seems to run in it
with a following code path.

erst_writer -> erst_write -> __erst_write_to_storage -> many of apei_exec_run -> 
ctx->ins_table[entry->instruction].run()

which are functions defined in erst_ins_type table i.e:

apei_exec_read_register -> apei_read -> acpi_os_read_memory64 -> acpi_os_ioremap -> ioremap_cache

which possibly involve IOMMU allocator.

I may cause a failure of  an erst driver if the panic happens in an interrupt context.

[Idea]

If we can remove ioremap_cache() from acpi_os_read_memory() as follows,
It is easy to fix this issue.
But I'm not sure if it is feasible because I can't see the reason of tying acpi_os_ioremap()  from a git log...

Any comment?

<snip>
@@ -918,10 +918,7 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u64 *value, u32 width)
 	virt_addr = acpi_map_vaddr_lookup(phys_addr, size);
 	if (!virt_addr) {
 		rcu_read_unlock();
-		virt_addr = acpi_os_ioremap(phys_addr, size);
-		if (!virt_addr)
-			return AE_BAD_ADDRESS;
-		unmap = true;
+		return AE_BAD_ADDRESS;
 	}
 
 	if (!value)
<snip>

Seiji
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux