[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D414A51F3D@USINDEM103.corp.hds.com>
Date: Tue, 22 Jan 2013 23:30:08 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: "Huang, Ying (ying.huang@...el.com)" <ying.huang@...el.com>,
"rjw@...k.pl" <rjw@...k.pl>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"H. Peter Anvin (hpa@...or.com)" <hpa@...or.com>,
"robert.moore@...el.com" <robert.moore@...el.com>,
"trenn@...e.de" <trenn@...e.de>,
"myron.stowe@...hat.com" <myron.stowe@...hat.com>
Subject: ERST: how to avoid a dynamic memory allocation in panic case
[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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists